robots.txt, sans sitemap déclaré et sans propriété vérifiée dans Google Search Console, les moteurs de recherche n’ont aucune garantie d’indexation fiable. Ce guide couvre la mise en place minimale mais complète pour un blog Jekyll.
User-agent: *
Allow: /
Sitemap: https://mondomaine.com/sitemap.xml
Un fichier statique à la racine du site suffit — pas besoin de plugin.
Le plugin officiel génère et maintient le sitemap sans configuration :
# _config.yml
plugins:
- jekyll-sitemap
Jekyll expose alors automatiquement /sitemap.xml, régénéré à chaque build avec la liste à jour des articles et pages.
plugins:
- jekyll-seo-tag
{% seo %}
Ce tag unique génère titre, description, Open Graph, Twitter Card et la balise generator à partir des champs déjà présents dans _config.yml (title, description, url) et le front matter de chaque article (description, image).
La méthode la plus simple pour un site statique est la balise meta, ajoutée directement dans le <head> du layout principal :
<meta name="google-site-verification" content="VOTRE_CODE_ICI" />
Dans Search Console : Paramètres → Propriété → Vérification du domaine → méthode ‘Balise HTML’. Le code fourni va directement dans le content de la meta tag, pas ailleurs.
Une fois la propriété vérifiée dans Search Console : Sitemaps → Ajouter un sitemap → renseigner sitemap.xml (l’URL complète n’est pas nécessaire, juste le chemin relatif). Le statut passe à “Sitemap envoyé” puis, après quelques heures, “Réussite” avec le nombre de pages découvertes.
curl -s https://mondomaine.com/robots.txt
curl -s https://mondomaine.com/sitemap.xml | head -20
curl -s https://mondomaine.com/ | grep google-site-verification
Si vous supprimez puis recréez la propriété dans Search Console, un nouveau code de vérification est généré à chaque fois — l’ancienne balise meta ne fonctionnera plus, il faut la remplacer avant de relancer la vérification.
robots.txt en place, pointant vers le sitemap.L’API stats officielle (/api/v0/stats/total) exige systématiquement un token Bearer, même avec le dashboard configuré en public :
curl -s https://MONCODE.goatcounter.com/api/v0/stats/total
# → {"error":"no Authorization header"}
Le endpoint public /counter/*.json, pensé pour être embarqué sans token, fonctionne en curl mais casse en fetch() depuis le navigateur :
Access to fetch at 'https://moncode.goatcounter.com/counter//.json?...'
from origin 'https://mondomaine.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present
La variante <img> avec /counter/*.svg contourne en théorie le CORS (une image n’y est pas soumise) — mais échoue quand même avec un 499/net::ERR_FAILED, reproductible aussi bien sur PC que sur mobile, sans lien avec un bloqueur de pub local.
Plutôt que de faire confiance au navigateur du visiteur, un plugin Jekyll récupère le chiffre une seule fois, pendant jekyll build/jekyll serve, et l’injecte directement dans le HTML statique généré — plus aucune requête réseau au chargement de la page.
# _plugins/goatcounter_stats.rb
require "net/http"
require "json"
require "date"
Jekyll::Hooks.register :site, :after_reset do |site|
code = site.config.dig("analytics", "goatcounter_code")
next if code.nil? || code.empty?
begin
end_date = Date.today
start_date = end_date - 30
uri = URI("https://#{code}.goatcounter.com/counter//.json?start=#{start_date}&end=#{end_date}")
Net::HTTP.start(uri.host, uri.port, use_ssl: true, open_timeout: 5, read_timeout: 5) do |http|
res = http.get(uri.request_uri)
if res.is_a?(Net::HTTPSuccess)
data = JSON.parse(res.body)
site.config["goatcounter_visitors"] = (data["count_unique"] || data["count"] || "0").to_i
end
end
rescue StandardError => e
Jekyll.logger.warn "goatcounter_stats:", "fetch failed (#{e.message})"
end
end
Une image ruby:3.3-alpine ne contient pas les certificats CA par défaut — Net::HTTP en HTTPS échoue silencieusement (ou plante le process Jekyll au démarrage) tant que le paquet ca-certificates n’est pas installé dans le Dockerfile.
Le widget se contente de lire une valeur déjà calculée — aucun script, aucun appel réseau côté visiteur :
<div class="stat-card">
{% if site.goatcounter_visitors %}
{% if site.goatcounter_visitors >= 1000 %}
<div class="stat-value">{{ site.goatcounter_visitors | divided_by: 1000.0 | round: 1 }}k</div>
{% else %}
<div class="stat-value">{{ site.goatcounter_visitors }}</div>
{% endif %}
{% else %}
<div class="stat-value">—</div>
{% endif %}
<div class="stat-label">Visitors / month</div>
</div>
# _config.yml
analytics:
goatcounter_code: "moncode"
docker compose -f docker-compose.public.yml up -d --build
docker logs infops-public | grep -i goatcounter # aucune erreur = OK
curl -s http://localhost:4000/ | grep -A3 "Visitors / month"
# → le chiffre doit apparaître directement dans le HTML, pas de "—"
Objectif : cacher Server/X-Powered-By pour tous les domaines internes, sauf le site vitrine où on assume volontairement la stack technique.
Premier réflexe naturel — et premier piège :
acl is_main_domain hdr(host) -i 50bvd.com
http-response del-header Server if !is_main_domain
En contexte http-response, hdr(host) n’est plus valable : ce fetch n’existe que côté requête. HAProxy refuse la règle avec “will never match because it only involves keywords that are incompatible with ‘frontend http-response header rule’“.
La solution consiste à capturer le host dès la requête dans une variable de transaction, puis à la relire côté réponse :
http-request set-var(txn.host) req.hdr(host)
acl is_main_domain var(txn.host) -m str -i 50bvd.com
http-response del-header Server if !is_main_domain
http-response del-header X-Powered-By if !is_main_domain
Une ACL basée sur var() n’a pas de type implicite — sans -m str, HAProxy refuse de démarrer avec ‘matching method must be specified first’.
Les directives errorfile classiques (dans defaults) ne couvrent que les erreurs générées par HAProxy lui-même (backend injoignable → 502/503/504, requête malformée → 400). Elles n’interceptent jamais un 404 ou un 500 renvoyé par un backend qui répond normalement.
Pour remplacer systématiquement n’importe quel code d’erreur — qu’il vienne d’un backend sain ou d’une panne détectée par HAProxy — sur frontend https_front :
http-response return status 404 content-type text/html \
file /etc/haproxy/errors/404.http \
hdr X-Frame-Options "SAMEORIGIN" \
hdr X-Content-Type-Options "nosniff" \
hdr Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" \
hdr Referrer-Policy "strict-origin-when-cross-origin" \
if { status 404 }
À répéter pour chaque code voulu (400, 403, 404, 408, 500, 502, 503, 504).
http-response return écrase entièrement la réponse d’origine, y compris les en-têtes de sécurité ajoutés par des règles précédentes — il faut les réinjecter directement sur la ligne return via hdr.
Un panel type Pterodactyl gère ses routes côté client (React/Vue) : une URL inexistante dans l’app renvoie quand même un HTTP 200 côté serveur, avec un “not found” purement visuel. Aucune règle HAProxy ne peut intercepter ce cas — seules les vraies pannes (backend injoignable, timeout) restent couvertes.
haproxy -c -f /etc/haproxy/haproxy.cfg
rcctl reload haproxy # ou rcctl restart haproxy si reload insuffisant
# Header masqué sur un service interne
curl -sI https://portainer.exemple.com/ | grep -i server
# Header conservé sur le site vitrine
curl -sI https://50bvd.com/ | grep -i server
# Page d'erreur personnalisée sur une route inexistante
curl -s https://50bvd.com/route-qui-nexiste-pas/ | head -c 200
| Sur OpenBSD, HAProxy tourne via rcctl et le shell par défaut est ksh — les astuces bash (sed -i sans argument, systemctl…) ne s’appliquent pas telles quelles. sed nécessite un argument vide explicite : sed -i ‘’ ‘s | … | … | ’. |
Server/X-Powered-By masqués sur tous les domaines internes, conservés uniquement sur le domaine choisi.jekyll build) servi ensuite par nginx ou Apache. Cette approche est la plus performante, mais elle impose un cycle build → copie des fichiers → redéploiement à chaque modification. Pour un blog personnel à faible trafic, ce guide propose une alternative volontairement plus simple : faire tourner le serveur jekyll serve (WEBrick) directement en conteneur, avec les sources montées en volume, reverse-proxifié par HAProxy.
Un pipeline build + nginx est plus rapide à servir, mais chaque modification de contenu impose de reconstruire l’image ou de resynchroniser un dossier de sortie. Pour un site de quelques articles, non critique, on peut accepter un serveur un peu moins rapide en échange d’une simplicité totale : modifier un fichier sur le disque suffit, Jekyll régénère le site tout seul.
Deux stages : base installe les dépendances Ruby, dev lance le serveur. Ce même stage sert aussi bien en développement local qu’en “production” — seule la commande de lancement change entre les deux docker-compose.yml.
FROM ruby:3.3-alpine AS base
RUN apk add --no-cache \
build-base git nodejs npm tzdata \
libffi-dev yaml-dev zlib-dev \
ca-certificates
WORKDIR /site
COPY Gemfile Gemfile.lock ./
RUN bundle install --jobs 4 --retry 3
FROM base AS dev
WORKDIR /site
EXPOSE 4000 35729
CMD ["bundle", "exec", "jekyll", "serve", \
"--host", "0.0.0.0", \
"--port", "4000", \
"--livereload", \
"--future", \
"--drafts"]
Sur Alpine, le paquet ca-certificates n’est pas installé par défaut. Sans lui, tout appel HTTPS sortant depuis un plugin Jekyll (Net::HTTP, API externe…) échoue avec une erreur SSL.
services:
jekyll-public:
build:
context: .
target: dev
container_name: infops-public
volumes:
- .:/site
- gem_cache:/usr/local/bundle
command: >
bundle exec jekyll serve
--host 0.0.0.0
--port 4000
ports:
- "4000:4000"
environment:
- JEKYLL_ENV=production
- TZ=Europe/Paris
restart: unless-stopped
volumes:
gem_cache:
Deux différences avec le compose de développement : pas de --drafts/--future (on ne publie que les articles réellement datés et publiés), et JEKYLL_ENV=production pour activer les blocs conditionnels ({% if jekyll.environment == "production" %}) comme le chargement des scripts d’analytics.
Le flag –incremental de Jekyll a un bug connu : il ne recharge pas toujours correctement les layouts/includes modifiés. Sur un site qui tourne en continu avec du contenu qui change souvent, mieux vaut laisser Jekyll régénérer intégralement à chaque changement détecté.
HAProxy termine le TLS et route le trafic vers le conteneur WEBrick en HTTP simple :
frontend https_front
bind *:443 ssl crt /etc/haproxy/combined.pem alpn h2,http/1.1
acl is_main_domain hdr(host) -i 50bvd.com
use_backend main_website if is_main_domain
backend main_website
option http-server-close
option forwardfor
option httpchk GET /
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
timeout tunnel 1h
server webserver 192.168.1.12:4000 check
docker compose -f docker-compose.public.yml up -d --build
# Depuis srv-docker
curl -sI http://localhost:4000/
# → HTTP/1.1 200 OK, Server: WEBrick/1.9.2
# Depuis l'extérieur, via HAProxy
curl -sI https://50bvd.com/
Toute modification sur le disque (article, layout, style) est reprise automatiquement en quelques secondes — pas de build ni de redéploiement séparé à orchestrer.
# Lister les conteneurs
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"
# Lister les volumes
docker volume ls
# Identifier les bind mounts (données hors volumes Docker)
docker inspect $(docker ps -aq) \
--format '{{.Name}}: {{range .Mounts}}{{.Type}}:{{.Source}}→{{.Destination}} {{end}}'
Exemple de stack à migrer :
| Conteneur | Données persistantes | Méthode |
|---|---|---|
| portainer | Volume portainer_data |
Export tar |
| app-custom | Build local + .env | Copier sources + rebuild |
| stateless-tools | Aucune | Re-pull image |
| site-web | Bind mount /root/site/ |
Copier dans l’archive home |
# Exclure les caches volumineux et régénérables
tar czf /tmp/home-backup.tar.gz \
--exclude=/root/jellyfin/cache \
--exclude=/root/.cache \
/root
ls -lh /tmp/home-backup.tar.gz
# Pour chaque volume nommé
for vol in $(docker volume ls -q); do
echo "Exporting $vol..."
docker run --rm \
-v "${vol}:/data" \
-v /tmp:/backup \
alpine tar czf "/backup/${vol}.tar.gz" /data
done
ls -lh /tmp/*.tar.gz
Créez une nouvelle VM (Proxmox ou autre) avec Debian 13 Netinstall, 50 Go de disque.
# Mise à jour système
apt update && apt upgrade -y
# Outils essentiels
apt install -y curl wget git vim sudo openssh-server netcat-openbsd
# Docker via le script officiel
curl -fsSL https://get.docker.com | sh
# Vérifier
docker version
# → Client/Server: Docker Engine 29.x.x
# Depuis la VM Debian — récupérer les archives
scp root@ANCIEN-IP:/tmp/home-backup.tar.gz /tmp/
scp root@ANCIEN-IP:/tmp/portainer_data.tar.gz /tmp/
# Extraire le home
tar xzf /tmp/home-backup.tar.gz -C /
# Importer le volume Portainer
docker volume create portainer_data
docker run --rm \
-v portainer_data:/data \
-v /tmp:/backup \
alpine tar xzf /backup/portainer_data.tar.gz -C /
# Vérifier
docker run --rm -v portainer_data:/data alpine ls /data
# → backups bin certs portainer.db ...
# /root/portainer-compose.yml
services:
portainer:
image: portainer/portainer-ee:latest
container_name: portainer
restart: always
ports:
- "8000:8000"
- "9443:9443"
volumes:
- portainer_data:/data
- /var/run/docker.sock:/var/run/docker.sock
portainer_agent:
image: portainer/agent:latest
container_name: portainer_agent
restart: always
ports:
- "9001:9001"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /var/lib/docker/volumes:/var/lib/docker/volumes
volumes:
portainer_data:
external: true
docker compose -f /root/portainer-compose.yml up -d
# Pas de données à migrer — juste re-pull et recréer
docker run -d --name it-tools --restart always -p 8080:80 corentinth/it-tools
docker run -d --name srv-kms --restart always -p 1688:1688 mikolatero/vlmcsd
cd /root/mon-app
docker compose up -d --build
Une fois tous les conteneurs vérifiés sur la nouvelle VM :
# 1. Arrêter l'ancienne VM (ne pas la supprimer immédiatement)
# 2. Assigner la même IP à la nouvelle VM (DHCP statique ou config réseau)
# Sur Debian 13 — modifier l'IP
nano /etc/network/interfaces
# Changer l'adresse IP
systemctl restart networking
# 3. Vérifier la connectivité
ip a
ping 8.8.8.8
Si les backends pointent vers une IP qui a changé :
# haproxy.cfg — mettre à jour l'IP des backends
backend mon_backend
server app NOUVELLE-IP:PORT check
haproxy -c -f /etc/haproxy/haproxy.cfg && systemctl reload haproxy
# Tous les conteneurs doivent être Up
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
# Tester chaque service
curl -sk https://mon-service.domaine.com -o /dev/null -w "%{http_code}"
# → 200
# Si problème — rallumer l'ancienne VM
# (gardez-la éteinte 48h avant suppression définitive)
# Remettre l'IP sur l'ancienne VM
# La nouvelle VM reprend son IP d'origine
En configurant la nouvelle VM sur une IP temporaire et en basculant l’IP uniquement une fois la migration validée, le downtime se réduit au temps du redémarrage réseau (~30 secondes).
La migration RHEL 8 → Debian 13 s’effectue proprement en moins de 2 heures pour une stack standard. La clé : sauvegarder les volumes Docker correctement et ne supprimer l’ancienne VM qu’après 48h de validation en production.
]]>Le panel Pterodactyl contacte le daemon Wings via le navigateur du client :
Navigateur → node.domaine.com:8080 → Wings
Depuis un réseau d’entreprise, le port 8080 est bloqué par le pare-feu. Le node apparaît en rouge dans le panel même si Wings fonctionne parfaitement en local.
Internet (port 443 uniquement)
│
▼
HAProxy — TLS termination
│
├── pterodactyl.domaine.com:443 → Panel (nginx:443)
└── node.domaine.com:443 → Wings (HTTP:8080)
# Wings écoute en HTTP sur 8080 — HAProxy gère le TLS
# PHP 8.3 via sury.org
curl -sSLo /usr/share/keyrings/deb.sury.org-php.gpg \
https://packages.sury.org/php/apt.gpg
echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] \
https://packages.sury.org/php/ trixie main" \
> /etc/apt/sources.list.d/php.list
apt update && apt install -y \
php8.3 php8.3-{cli,fpm,mysql,mbstring,bcmath,xml,curl,zip,gd,tokenizer} \
nginx mariadb-client certbot python3-certbot-nginx
mkdir -p /var/www/pterodactyl && cd /var/www/pterodactyl
curl -Lo panel.tar.gz \
https://github.com/pterodactyl/panel/releases/latest/download/panel.tar.gz
tar -xzf panel.tar.gz
chmod -R 755 storage/* bootstrap/cache/
composer install --no-dev --optimize-autoloader
cp .env.example .env
php artisan key:generate --force
php artisan p:environment:setup
php artisan p:environment:database
php artisan migrate --seed --force
php artisan p:user:make
chown -R www-data:www-data /var/www/pterodactyl
server {
listen 443 ssl;
server_name pterodactyl.domaine.com;
ssl_certificate /etc/letsencrypt/live/pterodactyl.domaine.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/pterodactyl.domaine.com/privkey.pem;
root /var/www/pterodactyl/public;
index index.php;
location / { try_files $uri $uri/ /index.php?$query_string; }
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
}
}
mkdir -p /etc/pterodactyl
curl -L -o /usr/local/bin/wings \
"https://github.com/pterodactyl/wings/releases/latest/download/wings_linux_amd64"
chmod u+x /usr/local/bin/wings
Dans le panel : Admin → Nodes → Créer un node :
node.domaine.com443 ← port public exposé par HAProxyCopier la config générée dans /etc/pterodactyl/config.yml.
Vérifier que Wings écoute en HTTP sur 8080 (pas 443) :
# /etc/pterodactyl/config.yml
api:
port: 8080 # Port interne — HAProxy proxifie vers ici
ssl:
enabled: false # HAProxy gère le TLS
# Service systemd
curl -o /etc/systemd/system/wings.service \
https://raw.githubusercontent.com/pterodactyl/wings/develop/wings.service
systemctl enable --now wings
# Vérifier
ss -tlnp | grep 8080
# → Wings écoute sur 0.0.0.0:8080
frontend https_front
bind *:443 ssl crt /etc/haproxy/combined.pem alpn h2,http/1.1
acl is_panel hdr(host) -i pterodactyl.domaine.com
acl is_node hdr(host) -i node.domaine.com
use_backend panel_backend if is_panel
use_backend wings_backend if is_node
backend panel_backend
option forwardfor
http-request set-header X-Forwarded-Proto https if { ssl_fc }
timeout tunnel 1h
server panel 192.168.x.x:443 check ssl verify none
backend wings_backend
mode http
option forwardfor
http-request set-header X-Forwarded-Proto https if { ssl_fc }
timeout tunnel 1h
server wings 192.168.x.x:8080 check
# Pas de "ssl" ici — Wings tourne en HTTP pur
Pour le backend Wings : juste ‘check’ sans ‘ssl’ — Wings écoute en HTTP. Pour le panel nginx qui écoute en HTTPS : ‘check ssl verify none’.
# Tester Wings via HAProxy
curl -sk https://node.domaine.com/api/system -o /dev/null -w "%{http_code}"
# → 401 (authentification requise — Wings répond correctement)
# Le node doit passer en vert dans le panel
# Autoriser Wings uniquement depuis HAProxy
iptables -A INPUT -p tcp --dport 8080 -s 192.168.x.11 -j ACCEPT # IP HAProxy
iptables -A INPUT -p tcp --dport 8080 -j DROP
# Port Panel nginx
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# SFTP Pterodactyl
iptables -A INPUT -p tcp --dport 2022 -j ACCEPT
# Persister
apt install -y iptables-persistent
netfilter-persistent save
Configurez un cron pour renouveler automatiquement les certs Let’s Encrypt et regénérer le combined.pem pour HAProxy (cat fullchain.pem privkey.pem > combined.pem).
# docker-compose.yml
services:
deming:
image: sourcentis/deming:latest
container_name: deming
restart: unless-stopped
ports:
- "8080:80"
environment:
APP_ENV: production
APP_KEY: ${APP_KEY}
DB_HOST: mariadb
DB_DATABASE: deming
DB_USERNAME: deming
DB_PASSWORD: ${DB_PASSWORD}
LDAP_HOST: ${LDAP_HOST}
LDAP_PORT: 389
LDAP_BASE_DN: ${LDAP_BASE_DN}
LDAP_USERNAME: ${LDAP_USERNAME}
LDAP_PASSWORD: ${LDAP_PASSWORD}
volumes:
- deming_storage:/var/www/html/storage
depends_on:
- mariadb
mariadb:
image: mariadb:10.11
container_name: deming-db
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
MYSQL_DATABASE: deming
MYSQL_USER: deming
MYSQL_PASSWORD: ${DB_PASSWORD}
volumes:
- deming_db:/var/lib/mysql
volumes:
deming_storage:
deming_db:
# Générer la clé APP Laravel
docker compose run --rm deming php artisan key:generate --show
# Copier la valeur dans .env
docker compose up -d
docker compose exec deming php artisan migrate --force
L’authentification LDAP échoue avec des attributs multiples :
LDAP Error: Invalid filter syntax
ldap_search(): Search: Bad search filter
Le filtre LDAP généré était syntaxiquement incorrect lors de l’utilisation de plusieurs attributs d’identification (ex: sAMAccountName ET mail) :
// Code original (bugué)
// Génère : (&(objectClass=user)(attr1=val)(attr2=val))
// Correct pour 1 attr, INVALIDE pour plusieurs en OR
$filter = "(&(objectClass=user)" . implode('', $conditions) . ")";
Le filtre correct pour plusieurs attributs en OR doit encapsuler dans (|...) :
// Pour 1 attribut : (&(objectClass=user)(sAMAccountName=foo)) ✅
// Pour plusieurs : (&(objectClass=user)(|(sAMAccountName=foo)(mail=foo@bar.com))) ✅
// Généré (bugué) : (&(objectClass=user)(sAMAccountName=foo)(mail=foo@bar.com)) ❌
// Après correction
if (count($conditions) > 1) {
$filter = "(&(objectClass=user)(|" . implode('', $conditions) . "))";
} else {
$filter = "(&(objectClass=user)" . $conditions[0] . ")";
}
À la première connexion d’un utilisateur LDAP non encore en base, l’auto-provisionnement échoue :
SQLSTATE[23000]: Integrity constraint violation:
1062 Duplicate entry 'null' for key 'users_email_unique'
Le code récupérait l’attribut mail depuis LDAP, mais en cas d’absence (compte de service, compte sans email configuré), il fallait à null hardcodé plutôt qu’utiliser le sAMAccountName comme fallback :
// Code original (bugué)
$email = $ldapUser->getAttribute('mail')[0] ?? null;
// → null si pas de mail → contrainte unique violée au second utilisateur sans mail
// Après correction — fallback sur sAMAccountName@domaine
$defaultDomain = config('ldap.default_domain', 'domain.local');
$email = $ldapUser->getAttribute('mail')[0]
?? ($ldapUser->getAttribute('sAMAccountName')[0] . '@' . $defaultDomain)
?? null;
# Depuis le conteneur
docker exec -it deming ldapsearch \
-H ldap://DC_IP \
-D "CN=svc-compte,OU=Services,DC=domain,DC=local" \
-w PASS \
-b "DC=domain,DC=local" \
"(sAMAccountName=testuser)" \
sAMAccountName mail displayName
# Tester le filtre corrigé manuellement
docker exec -it deming ldapsearch \
-H ldap://DC_IP \
-D "CN=svc-compte,OU=Services,DC=domain,DC=local" \
-w PASS \
-b "DC=domain,DC=local" \
"(&(objectClass=user)(|(sAMAccountName=testuser)(mail=test@domain.local)))"
# Fork + clone
git clone https://github.com/VOTRE_FORK/deming.git
cd deming
git checkout -b fix/ldap-filter-and-or
# Modifier le code (voir fixes ci-dessus)
# ...
git add .
git commit -m "Fix LDAP login filter incorrect AND/OR grouping with multiple attributes"
git push origin fix/ldap-filter-and-or
# → Ouvrir la PR sur github.com/sourcentis/deming
Les deux PRs ont été mergées dans la version 2026.06.16 :
Contribuer upstream profite à toute la communauté. Si vous trouvez un bug en déployant un projet open source, prenez 30 minutes pour soumettre une PR — c’est souvent simple et très apprécié.
backend deming_backend
option forwardfor
option http-server-close
http-request set-header X-Forwarded-Proto https if { ssl_fc }
timeout tunnel 1h
server deming 192.168.x.x:8080 check
| Composant | Détail |
|---|---|
| Modèle | Mac Pro 3.1 (Early 2008) |
| CPU | 2× Intel Xeon E5462 (Harpertown, 4c/4t × 2 = 8 threads) |
| RAM | 32 Go DDR2 ECC 800 MHz |
| Stockage boot | SSD 120 Go (SATA via adaptateur) |
| Stockage data | 4× HDD 2 To (ZFS raidz1) |
Flashez l’ISO sur une clé USB :
dd if=proxmox-ve_8.4.iso of=/dev/sdX bs=4M status=progress
Au démarrage du Mac Pro, maintenez Option pour sélectionner la clé USB. Le Mac Pro 3.1 boot en mode BIOS legacy — si la clé ne s’affiche pas, essayez un autre port USB (les ports arrière fonctionnent mieux).
Le Mac Pro 3.1 peut être capricieux avec certaines clés USB. Si ça bloque, gravez un DVD ou utilisez rEFInd comme bootloader intermédiaire.
Après installation, les VMs crashent avec cette erreur dans les logs KVM :
kvm: vcpu0, guest rip=0xffffffff8104b90c, error 1,
info 0: MSR_IA32_DEBUGCTL error
C’est un bug connu avec les Xeon Harpertown (architecture Penryn) — ces CPU ne supportent pas complètement le registre IA32_DEBUGCTL requis par KVM.
# Option 1 : modifier le paramètre du module
echo "options kvm-intel ignore_msrs=Y" > /etc/modprobe.d/kvm-intel.conf
# Recharger sans redémarrer
modprobe -r kvm_intel
modprobe kvm_intel ignore_msrs=Y
# Vérifier
cat /sys/module/kvm_intel/parameters/ignore_msrs
# → Y
# Appliquer définitivement
update-initramfs -u -k all
Après reboot, les VMs démarrent et tournent stablement.
Raidz1 avec 4 disques de 2 To = 6 To utilisables (1 disque de parité).
# Identifier les disques par leur ID stable (éviter /dev/sdX qui peut changer)
ls -la /dev/disk/by-id/ | grep -v part | grep ata
# Créer le pool
zpool create -o ashift=12 \
-O compression=lz4 \
-O atime=off \
-O xattr=sa \
-O dnodesize=auto \
datastore raidz1 \
/dev/disk/by-id/ata-DISK1 \
/dev/disk/by-id/ata-DISK2 \
/dev/disk/by-id/ata-DISK3 \
/dev/disk/by-id/ata-DISK4
# Vérifier
zpool status
zfs list
# ARC limité à 8 Go (éviter de tout consommer pour les VMs)
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
# Scrub hebdomadaire automatique (déjà configuré par Proxmox)
systemctl status zfs-scrub.timer
pvesm add zfspool datastore \
--pool datastore \
--sparse 1 \
--content images,rootdir
Ou via l’interface : Datacenter → Storage → Add → ZFS.
# Ajouter un SSD comme cache de lecture
zpool add datastore cache /dev/disk/by-id/ata-SSD
# Vérifier
zpool status
# → cache: SSD affiché
# /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp0s3
iface enp0s3 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports enp0s3
bridge-stp off
bridge-fd 0
Après plusieurs mois avec 8-10 VMs simultanées :
| Métrique | Valeur |
|---|---|
| CPU moyen | 15-40% |
| RAM utilisée | 22-28 Go / 32 |
| I/O ZFS (seq read) | ~150 Mo/s |
| I/O ZFS (seq write) | ~80 Mo/s |
| Température CPU | 45-55°C |
La ventilation Mac Pro (axiale, très silencieuse) gère parfaitement la thermique même sous charge.
Le Mac Pro 3.1 est une base homelab solide malgré ses 16 ans. Le seul vrai obstacle est le bug ignore_msrs — une fois corrigé, tout fonctionne parfaitement sous Proxmox 8.4.
Le Mac Pro 3.1 supporte jusqu’à 32 Go DDR2 ECC en 8 slots. Les barrettes appairées sont importantes pour les performances. Achetez en kits testés pour Mac Pro.
# Vérifier la résolution DNS du domaine AD
dig +short domaine.local _ldap._tcp.domaine.local SRV
# → doit retourner l'IP et le port LDAP du DC
# Ping vers le DC
ping dc1.domaine.local
# Vérifier les ports nécessaires
for port in 88 389 636; do
nc -zv dc1.domaine.local $port && echo "Port $port OK" || echo "Port $port FERMÉ"
done
Le DNS doit impérativement résoudre le domaine AD et les enregistrements SRV. Configurez les DCs comme serveurs DNS dans /etc/resolv.conf avant de commencer.
# /etc/resolv.conf
search domaine.local
nameserver 192.168.x.10 # DC1
nameserver 192.168.x.11 # DC2
# Vérifier
nslookup domaine.local
nslookup dc1.domaine.local
dnf install -y \
realmd \
sssd \
sssd-ad \
sssd-tools \
oddjob \
oddjob-mkhomedir \
adcli \
samba-common-tools \
krb5-workstation \
openldap-clients
# Découverte du domaine (sans jonction)
realm discover domaine.local
# Jonction au domaine
realm join -U administrateur domaine.local
# Entrez le mot de passe du compte AD quand demandé
# Vérifier la jonction
realm list
Sortie attendue :
domaine.local
type: kerberos
realm-name: DOMAINE.LOCAL
domain-name: domaine.local
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U@domaine.local
login-policy: allow-realm-logins
Le fichier /etc/sssd/sssd.conf est généré automatiquement par realm join, mais quelques ajustements sont recommandés :
# /etc/sssd/sssd.conf
[sssd]
domains = domaine.local
config_file_version = 2
services = nss, pam
[domain/domaine.local]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = DOMAINE.LOCAL
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = domaine.local
use_fully_qualified_names = False # ← Permet login sans @domaine.local
ldap_id_mapping = True
access_provider = ad
# Performance
ad_gpo_access_control = disabled # Désactiver GPO Linux (optionnel)
ldap_referrals = false
# Cache
cache_credentials = true
offline_credentials_expiration = 7
# Timeout
ldap_network_timeout = 3
ldap_opt_timeout = 3
Sans cette option, les utilisateurs doivent se connecter avec utilisateur@domaine.local. Avec False, ‘utilisateur’ suffit — beaucoup plus pratique.
# Appliquer les permissions (obligatoire)
chmod 600 /etc/sssd/sssd.conf
# Redémarrer SSSD
systemctl restart sssd
systemctl enable sssd
# Activer la création automatique du home au premier login
authselect select sssd with-mkhomedir --force
# Activer le service oddjobd
systemctl enable --now oddjobd
# Vérifier qu'un utilisateur AD est visible
id utilisateur@domaine.local
# Avec use_fully_qualified_names = False :
id utilisateur
# Tester l'authentification Kerberos
kinit administrateur@DOMAINE.LOCAL
klist # Affiche le ticket Kerberos
# Tester la connexion SSH avec un compte AD
ssh utilisateur@localhost
Par défaut, tous les utilisateurs AD peuvent se connecter. Limitez l’accès :
# Autoriser uniquement le groupe "Linux-Admins" AD
realm permit -g 'Linux-Admins@domaine.local'
# Interdire tout le monde sauf les autorisés
realm deny --all
realm permit -g 'Linux-Admins@domaine.local'
realm permit -g 'Linux-Users@domaine.local'
# Vérifier
realm list
Créez un fichier sudoers pour vos groupes AD :
# /etc/sudoers.d/ad-admins
# Donner sudo complet au groupe "Linux-Admins" AD
%Linux-Admins@domaine.local ALL=(ALL) ALL
# Sudo sans mot de passe pour les admins infra
%Linux-Infra-Admins@domaine.local ALL=(ALL) NOPASSWD: ALL
# Vérifier la syntaxe
visudo -c -f /etc/sudoers.d/ad-admins
# Tester
su - utilisateur-admin@domaine.local
sudo whoami # → root
journalctl -u sssd -n 50 --no-pager
# Problème fréquent : permissions sssd.conf
chmod 600 /etc/sssd/sssd.conf
chown root:root /etc/sssd/sssd.conf
# Nettoyer le cache SSSD (si utilisateurs "fantômes")
sss_cache -E
systemctl restart sssd
# Vérifier la connexion LDAP directement
ldapsearch -H ldap://dc1.domaine.local \
-D "CN=svc-linux,OU=Services,DC=domaine,DC=local" \
-w PASS \
-b "DC=domaine,DC=local" \
"(sAMAccountName=utilisateur)"
# Forcer la synchronisation
sss_cache -u utilisateur
id utilisateur
# Vérifier le ticket
klist
# Renouveler manuellement
kinit utilisateur@DOMAINE.LOCAL
# Synchroniser l'heure (Kerberos est sensible à la dérive)
timedatectl status
chronyc tracking
# Si décalage > 5 min → Kerberos échoue
chronyc makestep
realm leave domaine.local
# Le compte machine est supprimé de l'AD
# Test complet
getent passwd utilisateur # L'utilisateur est visible
getent group 'Linux-Admins' # Le groupe AD est visible
su - utilisateur # Connexion → home créé automatiquement
sudo -l # Droits sudo corrects
Les utilisateurs AD peuvent désormais se connecter en SSH sur le serveur Linux avec leurs identifiants du domaine. Le home directory est créé automatiquement au premier login.
Si vous ne pouvez pas joindre la machine au domaine (environnements restrictifs), une alternative est le bind LDAP simple via nslcd :
dnf install -y nss-pam-ldapd nslcd
# /etc/nslcd.conf
uri ldap://dc1.domaine.local
base dc=domaine,dc=local
binddn CN=svc-linux,OU=Services,DC=domaine,DC=local
bindpw VOTRE_MOT_DE_PASSE
ssl start_tls
tls_reqcert never
scope sub
filter passwd (&(objectClass=user)(memberOf=CN=Linux-Users,OU=Groupes,DC=domaine,DC=local))
map passwd uid sAMAccountName
map passwd homeDirectory unixHomeDirectory
map passwd gecos displayName
Cette méthode est moins intégrée (pas de Kerberos, pas de SSO) mais fonctionne dans des environnements contraints.
]]>Appareil (téléphone, PC, TV...)
│ Requête DNS : pub.example.com
▼
Pi-hole (serveur DNS local)
│ Liste noire : pub.example.com → BLOQUÉ → 0.0.0.0
│ Domaine légitime → forwarde vers 1.1.1.1
▼
Internet (uniquement pour les domaines légitimes)
Pi-hole répond 0.0.0.0 pour les domaines publicitaires — l’appareil ne charge jamais le contenu.
Le Raspberry Pi Zero 2W (~18€) suffit amplement pour Pi-hole sur un réseau domestique. Le Pi 4 est surdimensionné pour cet usage mais permet d’héberger d’autres services en même temps.
1. Téléchargez Raspberry Pi Imager
2. Dans l’imager, cliquez sur l’icône ⚙️ avant de flasher pour préconfigurer :
pihole)3. Flashez la carte SD avec Raspberry Pi OS Lite (64-bit)
4. Insérez la carte et démarrez le Pi. Connectez-vous en SSH :
ssh pi@pihole.local
# ou ssh pi@IP_DU_PI
Pi-hole doit toujours avoir la même IP pour servir de DNS :
# Option 1 : réservation DHCP dans votre box/routeur (recommandé)
# Trouvez l'adresse MAC du Pi dans l'interface de votre routeur
# et créez une réservation DHCP
# Option 2 : IP statique sur le Pi
sudo nano /etc/dhcpcd.conf
# Ajouter à la fin :
interface eth0
static ip_address=192.168.1.100/24
static routers=192.168.1.1
static domain_name_servers=127.0.0.1
curl -sSL https://install.pi-hole.net | bash
L’installateur interactif vous guidera :
eth0 (câble) ou wlan0 (Wi-Fi)À la fin, notez le mot de passe admin généré.
Si vous ratez le mot de passe, vous pouvez le changer à tout moment avec : pihole -a -p nouveau-mot-de-passe
Ouvrez http://192.168.1.100/admin dans votre navigateur.
pihole -g
Dans l’interface : Group Management → Adlists, ajoutez :
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
https://someonewhocares.org/hosts/zero/hosts
https://raw.githubusercontent.com/PolishFiltersTeam/KADhosts/master/KADhosts.txt
https://adaway.org/hosts.txt
Après ajout : Tools → Update Gravity pour télécharger les listes.
C’est l’étape clé : tous les appareils du réseau doivent utiliser Pi-hole comme DNS.
Dans l’interface de votre box/routeur :
192.168.1.100 (IP du Pi)1.1.1.1 (fallback si Pi-hole tombe)Sur certaines box, il faut redémarrer les appareils pour qu’ils obtiennent le nouveau DNS.
Après quelques heures de fonctionnement :
| Métrique | Valeur typique |
|---|---|
| Requêtes bloquées | 20-35% |
| Domaines dans la liste noire | 150 000 - 300 000 |
| Latence DNS ajoutée | < 1ms en LAN |
| RAM utilisée (Pi Zero 2W) | ~80 Mo |
# Statut Pi-hole
pihole status
# Voir les requêtes en temps réel
pihole -t
# Mettre à jour Pi-hole
pihole -up
# Désactiver temporairement (300 secondes)
pihole disable 300
pihole enable
# Whitelister un domaine
pihole -w domaine.com
# Blacklister un domaine manuellement
pihole -b domaine-pub.com
# Statistiques rapides
pihole -c
# Chercher dans les logs
pihole -t | grep "nom-du-site.com"
# Whitelister
pihole -w nom-du-site.com
# Vérifier quel DNS un appareil utilise (depuis cet appareil)
# Windows :
nslookup google.com
# → Server: doit afficher l'IP de Pi-hole
# Linux/Mac :
dig google.com | grep SERVER
# Vérifier le service
sudo systemctl status pihole-FTL
# Redémarrer si nécessaire
sudo systemctl restart pihole-FTL
Sur mon Raspberry Pi, Pi-hole tourne en conteneur Docker avec vlmcsd (serveur KMS) sur la même machine :
services:
pihole:
image: pihole/pihole:latest
container_name: pihole
restart: unless-stopped
ports:
- "53:53/tcp"
- "53:53/udp"
- "80:80/tcp"
environment:
TZ: Europe/Paris
WEBPASSWORD: votre-mot-de-passe
PIHOLE_DNS_: 94.140.14.14;1.1.1.1
volumes:
- ./etc-pihole:/etc/pihole
- ./etc-dnsmasq.d:/etc/dnsmasq.d
vlmcsd:
image: mikolatero/vlmcsd:latest
container_name: vlmcsd
restart: unless-stopped
ports:
- "1688:1688"
Sur mon réseau, Pi-hole bloque en moyenne 28% des requêtes DNS — principalement de la publicité, des trackers et de la télémétrie Windows et Android.
Pi-hole est l’un des projets homelab avec le meilleur rapport effort/résultat. Une fois installé, il fonctionne de manière transparente pour tous les appareils du réseau sans aucune configuration côté client.
]]>