vault backup: 2026-02-28 01:41:39
This commit is contained in:
3
.obsidian/community-plugins.json
vendored
3
.obsidian/community-plugins.json
vendored
@@ -4,5 +4,6 @@
|
||||
"dataview",
|
||||
"find-unlinked-files",
|
||||
"obsidian-importer",
|
||||
"obsidian-linter"
|
||||
"obsidian-linter",
|
||||
"auto-note-mover"
|
||||
]
|
||||
2182
.obsidian/plugins/auto-note-mover/main.js
vendored
Normal file
2182
.obsidian/plugins/auto-note-mover/main.js
vendored
Normal file
File diff suppressed because it is too large
Load Diff
10
.obsidian/plugins/auto-note-mover/manifest.json
vendored
Normal file
10
.obsidian/plugins/auto-note-mover/manifest.json
vendored
Normal file
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"id": "auto-note-mover",
|
||||
"name": "Auto Note Mover",
|
||||
"version": "1.2.0",
|
||||
"minAppVersion": "0.12.0",
|
||||
"description": "Auto Note Mover will automatically move the active notes to their respective folders according to the rules.",
|
||||
"author": "faru",
|
||||
"authorUrl": "https://github.com/farux/",
|
||||
"isDesktopOnly": false
|
||||
}
|
||||
127
articles/2026/Installer un serveur de cache APT avec https.md
Normal file
127
articles/2026/Installer un serveur de cache APT avec https.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
title: Installer un serveur de cache APT avec https
|
||||
description:
|
||||
tags: []
|
||||
date: 2026-02-28 01:25
|
||||
lastmod: 2026-02-28 01:28
|
||||
type:
|
||||
- article
|
||||
category:
|
||||
- "[[Guide]]"
|
||||
status: brouillon
|
||||
---
|
||||
Pour mettre en cache du contenu **HTTPS** (et donc réellement économiser de la bande passante sur des dépôts comme Docker, Nodesource ou Google Cloud), la méthode "PassThrough" ne suffit plus car elle ne fait que laisser passer le flux chiffré sans le lire.
|
||||
|
||||
Pour que le serveur de cache puisse lire et stocker le contenu, il doit intercepter la connexion. Voici comment configurer une architecture **Man-in-the-Middle (MitM)** propre et sécurisée pour votre infrastructure locale.
|
||||
|
||||
---
|
||||
|
||||
## Le Concept : Proxy HTTPS Transparent
|
||||
|
||||
Dans ce scénario, nous allons utiliser **Squid** avec la fonctionnalité **SSL Peek-and-Splice**.
|
||||
|
||||
1. Le serveur de cache possède sa propre **Autorité de Certification (CA)**.
|
||||
|
||||
2. Vous installez ce certificat CA sur tous vos clients comme "Autorité de confiance".
|
||||
|
||||
3. Lorsqu'un client demande un paquet via HTTPS, le serveur génère un certificat à la volée, déchiffre la requête, vérifie son cache, et rechiffre le flux vers le client.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 1. Génération du certificat CA auto-signé
|
||||
|
||||
Sur votre serveur de cache, générez la clé et le certificat qui serviront à signer les requêtes interceptées :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
# Créer un dossier pour les certificats
|
||||
sudo mkdir -p /etc/squid/ssl_cert
|
||||
sudo openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 \
|
||||
-extensions v3_ca -keyout /etc/squid/ssl_cert/myCA.pem \
|
||||
-out /etc/squid/ssl_cert/myCA.pem
|
||||
```
|
||||
|
||||
> **Important :** Le fichier `myCA.pem` contient votre clé privée. Protégez-le avec des permissions strictes (`chmod 400`).
|
||||
|
||||
---
|
||||
|
||||
## 2. Configuration de Squid (Serveur de Cache)
|
||||
|
||||
Installez Squid avec le support SSL (vérifiez que votre version supporte `--with-openssl`) :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
sudo apt update && sudo apt install squid -y
|
||||
```
|
||||
|
||||
Modifiez la configuration `/etc/squid/squid.conf` pour inclure ces directives :
|
||||
|
||||
Plaintext
|
||||
|
||||
```
|
||||
# Port d'écoute avec interception SSL
|
||||
http_port 3128 ssl-bump \
|
||||
cert=/etc/squid/ssl_cert/myCA.pem \
|
||||
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
|
||||
|
||||
# Définition de la stratégie d'interception
|
||||
acl step1 at_step SslBump1
|
||||
ssl_bump peek step1
|
||||
ssl_bump bump all
|
||||
|
||||
# Cache des fichiers (ajustez la taille selon vos besoins)
|
||||
cache_dir ufs /var/spool/squid 10000 16 256
|
||||
maximum_object_size 1024 MB
|
||||
```
|
||||
|
||||
Initialisez la base de données des certificats dynamiques :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
sudo /usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 4MB
|
||||
sudo chown -R proxy:proxy /var/lib/squid/ssl_db
|
||||
sudo systemctl restart squid
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Configuration du Client (Étape CRUCIALE)
|
||||
|
||||
Sans cette étape, vos clients bloqueront la connexion pour "tentative d'interception" (HSTS/SSL Pinning).
|
||||
|
||||
### A. Importer le certificat CA
|
||||
|
||||
Copiez le fichier `myCA.pem` du serveur vers le client, puis :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
sudo cp myCA.pem /usr/local/share/ca-certificates/my-proxy-ca.crt
|
||||
sudo update-ca-certificates
|
||||
```
|
||||
|
||||
### B. Configurer APT pour utiliser le proxy
|
||||
|
||||
Éditez `/etc/apt/apt.conf.d/00proxy` :
|
||||
|
||||
Plaintext
|
||||
|
||||
```
|
||||
Acquire::http::Proxy "http://IP_SERVEUR:3128";
|
||||
Acquire::https::Proxy "http://IP_SERVEUR:3128";
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Avantages et Risques
|
||||
|
||||
|**Avantages**|**Risques / Inconvénients**|
|
||||
|---|---|
|
||||
|**Vraie mise en cache** du HTTPS (Gain de temps massif).|**Point de défaillance unique** pour la sécurité.|
|
||||
|Réduction drastique de la bande passante externe.|Nécessite d'installer le certificat sur **chaque** client.|
|
||||
|Contrôle total sur les paquets entrant dans le réseau.|Incompatible avec certains dépôts qui utilisent le _Certificate Pinning_.|
|
||||
|
||||
131
articles/2026/Installer un serveur de cache APT.md
Normal file
131
articles/2026/Installer un serveur de cache APT.md
Normal file
@@ -0,0 +1,131 @@
|
||||
---
|
||||
title: Installer un serveur de cache APT
|
||||
description:
|
||||
tags:
|
||||
date: 2026-02-28 01:26
|
||||
lastmod: 2026-02-28 01:26
|
||||
type:
|
||||
- article
|
||||
category:
|
||||
- "[[Guide]]"
|
||||
status: brouillon
|
||||
---
|
||||
Installer un serveur de cache APT (comme **Apt-Cacher-NG**) est une excellente initiative pour économiser de la bande passante et accélérer les mises à jour de vos serveurs ou VMs Linux.
|
||||
|
||||
Cependant, le passage au **HTTPS** pour les dépôts complique un peu la donne : par définition, le HTTPS est conçu pour empêcher les interceptions (ce que fait un cache). Pour contourner cela sans compromettre la sécurité, nous allons configurer un tunnel "CONNECT".
|
||||
|
||||
---
|
||||
|
||||
## 1. Installation de Apt-Cacher-NG
|
||||
|
||||
Commencez par installer le service sur la machine qui servira de serveur de cache (Debian ou Ubuntu) :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
sudo apt update
|
||||
sudo apt install apt-cacher-ng -y
|
||||
```
|
||||
|
||||
Le service écoute par défaut sur le port **3142**. Vous pouvez vérifier qu'il tourne bien en accédant à `http://IP_DU_SERVEUR:3142`.
|
||||
|
||||
---
|
||||
|
||||
## 2. Configuration pour le support HTTPS
|
||||
|
||||
Comme le cache ne peut pas "décrypter" le flux HTTPS (à moins de faire une attaque Man-in-the-Middle complexe et peu recommandée), la solution standard est d'autoriser le serveur à agir comme un **proxy tunnel**.
|
||||
|
||||
### Sur le serveur de cache :
|
||||
|
||||
Éditez le fichier de configuration :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
sudo nano /etc/apt-cacher-ng/acng.conf
|
||||
```
|
||||
|
||||
Cherchez et modifiez (ou ajoutez) la ligne suivante pour autoriser le port 443 :
|
||||
|
||||
Plaintext
|
||||
|
||||
```
|
||||
PassThroughPattern: ^(.*):443$
|
||||
```
|
||||
|
||||
_Note : Cela permet au client de passer à travers le cache pour le HTTPS. Les fichiers ne seront pas "mis en cache" de la même manière que le HTTP simple, mais cela centralise vos flux._
|
||||
|
||||
Redémarrez le service :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
sudo systemctl restart apt-cacher-ng
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Configuration des Clients
|
||||
|
||||
C'est ici que la magie opère. Vous ne devez pas modifier vos fichiers `sources.list`, mais dire à APT d'utiliser votre serveur comme proxy.
|
||||
|
||||
### Méthode A : Configuration globale (Recommandé)
|
||||
|
||||
Créez un fichier de configuration sur chaque machine cliente :
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
sudo nano /etc/apt/apt.conf.d/00aptproxy
|
||||
```
|
||||
|
||||
Ajoutez la ligne suivante (remplacez par l'IP de votre serveur) :
|
||||
|
||||
Plaintext
|
||||
|
||||
```
|
||||
Acquire::http::Proxy "http://192.168.1.50:3142";
|
||||
Acquire::https::Proxy "http://192.168.1.50:3142";
|
||||
```
|
||||
|
||||
### Cas particulier : Le "HTTPS-over-HTTP"
|
||||
|
||||
Si vous voulez vraiment mettre en cache le contenu HTTPS, la méthode la plus propre est de forcer APT à utiliser le protocole HTTP vers le cache, et de laisser le serveur de cache s'occuper du HTTPS vers l'extérieur.
|
||||
|
||||
Pour cela, dans votre `sources.list` client, remplacez `https://` par `http://` et utilisez le mapping dans `acng.conf`. Mais attention, cela demande une maintenance plus lourde. La méthode du **PassThrough** (étape 2) est la plus robuste.
|
||||
|
||||
---
|
||||
|
||||
## 4. Maintenance et Statistiques
|
||||
|
||||
L'un des grands avantages d'Apt-Cacher-NG est son interface web. Elle vous permet de voir combien de giga-octets vous avez économisés.
|
||||
|
||||
- **Interface :** `http://IP_DU_SERVEUR:3142/acng-report.html`
|
||||
|
||||
- **Expiration du cache :** Le serveur gère seul le nettoyage, mais vous pouvez forcer une purge via l'interface web pour supprimer les paquets obsolètes.
|
||||
|
||||
|
||||
|**Fonctionnalité**|**Action**|
|
||||
|---|---|
|
||||
|**Logs**|`/var/log/apt-cacher-ng/`|
|
||||
|**Stockage des paquets**|`/var/cache/apt-cacher-ng/`|
|
||||
|**Sécurité**|Pensez à limiter l'accès au port 3142 via votre pare-feu (UFW/Iptables) aux IPs de votre réseau local.|
|
||||
|
||||
---
|
||||
|
||||
### Résumé de l'architecture
|
||||
|
||||
1. **Le Client** demande un paquet.
|
||||
|
||||
2. **APT** voit la configuration proxy et envoie la requête au serveur de cache.
|
||||
|
||||
3. **Le Serveur de cache** vérifie s'il a déjà le paquet.
|
||||
|
||||
- Si oui : il le sert instantanément.
|
||||
|
||||
- Si non : il le télécharge, le stocke et le sert au client.
|
||||
|
||||
4. Pour le **HTTPS**, il crée un tunnel direct sans stockage local (sauf configuration spécifique).
|
||||
|
||||
|
||||
Souhaitez-vous que je vous aide à rédiger un script d'automatisation (Ansible ou Bash) pour déployer cette configuration sur 50 clients d'un coup ?
|
||||
@@ -1,15 +0,0 @@
|
||||
Nom du destinataire Adresse complète Code Postal - Ville Fait à Ville, le 23 février 2026
|
||||
|
||||
Objet : Demande de remboursement des frais de participation au jeu « [Nom du jeu] »
|
||||
|
||||
Madame, Monsieur,
|
||||
|
||||
J’ai participé à votre jeu-concours « [Nom du jeu] » diffusé le [date de diffusion] sur [nom de la chaîne ou de la station] en répondant à la question posée par SMS au [numéro de participation] dans le cadre du tirage au sort permettant de remporter [nature du gain].
|
||||
|
||||
Comme l’atteste le relevé téléphonique ci-joint, ma participation a entraîné l’envoi de [nombre] SMS surtaxé(s) d’un montant total de [montant en euros]. Conformément aux dispositions de votre règlement prévoyant la possibilité d’un remboursement des frais de participation, je vous prie de bien vouloir procéder au remboursement de cette somme.
|
||||
|
||||
Je sollicite également la prise en charge des frais d’affranchissement liés à l’envoi de la présente demande, soit le montant d’un timbre au tarif lettre verte en vigueur.
|
||||
|
||||
Vous trouverez ci-joint les pièces justificatives nécessaires : copie de mon relevé téléphonique, relevé d’identité bancaire, ainsi que le formulaire de remboursement téléchargé depuis votre site Internet.
|
||||
|
||||
Dans l’attente de votre retour, veuillez recevoir, Madame, Monsieur, mes salutations respectueuses.
|
||||
Reference in New Issue
Block a user