Fix spelling and grammar mistakes across EN and FR content (chapter C)
Co-Authored-By: Claude Sonnet 5 <[email protected]>
This commit is contained in:
Djeex
@@ -9,7 +9,7 @@ navigation:
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
## Scripts et projets annexes
|
||||
|
||||
Cette section rassemble mes projets Python et Bash écrits en chemin : des scripts qui automatisent une des usages précis, répond à des besoins particuliers, créés au fil du temps. Vous les trouverez peut-être utiles, les voici en vrac.
|
||||
Cette section rassemble mes projets Python et Bash écrits en chemin : des scripts qui automatisent un des usages précis, répondent à des besoins particuliers, créés au fil du temps. Vous les trouverez peut-être utiles, les voici en vrac.
|
||||
|
||||
### Python
|
||||
|
||||
|
||||
@@ -6,11 +6,11 @@ description: Un bot Python qui surveille la disponibilité des GPU en temps rée
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Depuis déjà 4 ans, la pénurie de materiel electronique fait rage. Et les cartes graphiques ne sont pas épargnées. En 2020, j'ai du attendre 2 mois pour obtenir mon exemplaire de RTX 3080, et pour cela j'ai du m'inscrire sur [JV Hardware](https://discord.gg/gxffg3GA96) où une poignée de geek avait mis en place un bot qui envoyait un ping lorsqu'elles étaient disponibles.
|
||||
Depuis déjà 4 ans, la pénurie de materiel electronique fait rage. Et les cartes graphiques ne sont pas épargnées. En 2020, j'ai dû attendre 2 mois pour obtenir mon exemplaire de RTX 3080, et pour cela j'ai dû m'inscrire sur [JV Hardware](https://discord.gg/gxffg3GA96) où une poignée de geek avait mis en place un bot qui envoyait un ping lorsqu'elles étaient disponibles.
|
||||
|
||||
4 ans après et 5000 abonnés plus tard, vient la sortie des RTX 5000. Et là aucun bot dispo sur le marché ne semble fonctionner correctement. Je ne parle même pas d'un certain "influenceur" qui se permet de faire payer l'accès à son bot qui ne fonctionne meme pas. Il copie à la main les alertes provenant d'autres serveurs, comme le notre qui ont résolu le problème.
|
||||
4 ans après et 5000 abonnés plus tard, vient la sortie des RTX 5000. Et là aucun bot dispo sur le marché ne semble fonctionner correctement. Je ne parle même pas d'un certain "influenceur" qui se permet de faire payer l'accès à son bot qui ne fonctionne même pas. Il copie à la main les alertes provenant d'autres serveurs, comme le nôtre qui ont résolu le problème.
|
||||
|
||||
Quoiqu'il en soit, désireux d'obtenir une RTX 5090 pour ma machine dédiée à l'IA, je me suis dit qu'il était peut etre le temps de plonger dans le monde de python et de ChatGPT pour m'épauler. A l'aide d'un autre membre du serveur, KevOut, qui a principalement guidé sur le principe de départ et les sources des différentes API, j'ai réussi à obtenir un bot propre, fonctionnel, qui envoie différents types d'alertes via Discord. Avec un simple conteneur docker à déployer.
|
||||
Quoiqu'il en soit, désireux d'obtenir une RTX 5090 pour ma machine dédiée à l'IA, je me suis dit qu'il était peut-être le temps de plonger dans le monde de python et de ChatGPT pour m'épauler. A l'aide d'un autre membre du serveur, KevOut, qui a principalement guidé sur le principe de départ et les sources des différentes API, j'ai réussi à obtenir un bot propre, fonctionnel, qui envoie différents types d'alertes via Discord. Avec un simple conteneur docker à déployer.
|
||||
|
||||
Après moult déconvenues, je suis passé de ceci :
|
||||
|
||||
|
||||
@@ -6,21 +6,21 @@ description: Un script Python pour synchroniser automatiquement les listes CIDR
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
AdGuard Home est une solution merveilleuse pour filter ses requêtes DNS et ainsi se débarasser de la publicité ou des DNS des fournisseurs d'accès, ou encore réécrire des requetes.
|
||||
AdGuard Home est une solution merveilleuse pour filtrer ses requêtes DNS et ainsi se débarrasser de la publicité ou des DNS des fournisseurs d'accès, ou encore réécrire des requêtes.
|
||||
|
||||
Quand c'est en local, c'est très chouette. Mais quand on veut que tout ses appareils en profitent même à l'exterieur, on est obligé de l'exposer sur le net. Et n'importe qui peut s'en servir et saturer le petit remote à 1€ qu'on a pris pour l'heberger.
|
||||
Quand c'est en local, c'est très chouette. Mais quand on veut que tous ses appareils en profitent même à l'extérieur, on est obligé de l'exposer sur le net. Et n'importe qui peut s'en servir et saturer le petit remote à 1€ qu'on a pris pour l'héberger.
|
||||
|
||||
AdGuard permet d'avoir des listes de clients autorisés ou bloqués. Problème, pour autoriser un client il faut son IP, et dans le cas d'un téléphone sur le réseau mobile, beh elle change régulièrement. L'idée est donc plutot de bloquer des listes générales plutot que d'autoriser des IP qui de toute façon changent régulièrement.
|
||||
AdGuard permet d'avoir des listes de clients autorisés ou bloqués. Problème, pour autoriser un client il faut son IP, et dans le cas d'un téléphone sur le réseau mobile, beh elle change régulièrement. L'idée est donc plutôt de bloquer des listes générales plutôt que d'autoriser des IP qui de toute façon changent régulièrement.
|
||||
|
||||
CIDRE est un outil qui permet de synchroniser des listes de plages IP géolocalisées mises à jour régulièrement avec un pare feu. Plutot que de faire tourner CIDRE sur le remote complet avec des règles de pare feu complexes, je me suis dit qu'il fallait simplement s'arranger pour ajouter les plages IP à jour que CIDRE propose au systeme de block list d'AdGuard, selon les pays que l'on souhaite bloquer.
|
||||
CIDRE est un outil qui permet de synchroniser des listes de plages IP géolocalisées mises à jour régulièrement avec un pare feu. Plutôt que de faire tourner CIDRE sur le remote complet avec des règles de pare-feu complexes, je me suis dit qu'il fallait simplement s'arranger pour ajouter les plages IP à jour que CIDRE propose au système de block list d'AdGuard, selon les pays que l'on souhaite bloquer.
|
||||
|
||||
C'est ainsi qu'est né AdGuard CIDRE Sync, un conteneur qui synchronise régulièrement la block list d'AdGuard avec les plages IP recensées par CIDRE à la fréquence que vous voulez.
|
||||
|
||||
L'idée etant de :
|
||||
L'idée étant de :
|
||||
|
||||
- Backup le fichier de conf d'AdGuard au premier lancement (le fichier jamais touché par le robot est ainsi conservé au cas où)
|
||||
- Télécharger la liste des pays selectionnés via une variable d'environnement
|
||||
- Permettre d'ajouter soi-meme des IP "à la main" dans un fichier
|
||||
- Télécharger la liste des pays sélectionnés via une variable d'environnement
|
||||
- Permettre d'ajouter soi-même des IP "à la main" dans un fichier
|
||||
- Concaténer le tout, backup le fichier de conf (dernière update), et injecter la liste dans la bonne section du fichier de conf d'AdGuard
|
||||
- Recharger AdGuard en relançant le container (accès au socket via docker socket proxy pour limiter les permissions)
|
||||
|
||||
|
||||
@@ -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]
|
||||
|
||||
Reference in New Issue
Block a user