# Rapport Hermes — 2026-06-07_11-00
> Branche : `hermes/daily-work` · Fichiers analysés : 5

---
## Résumé
- ✅ À jour : 5
- ⚠️  À améliorer : 0

## ✅ `admin/infra/dnsmasq.md` — 8/10

**Statut** : à_jour  
**Résumé** : Le document dnsmasq.md est complet et à jour, couvrant la configuration, les tests et les résolutions de problèmes courants. Il inclut des instructions pour les opérations courantes et des fixes pour les problèmes connus.  

**Problèmes :**
- La section 'Ajouter une entrée DNS' mentionne un template MetalLB mais ne précise pas exactement où ajouter la ligne 'address=/.lab.local/192.168.10.200' dans le template.
- Le problème connu lié à l'interface USB n'explique pas pourquoi cette interface cause des conflits avec le démarrage de dnsmasq.

**Suggestions :**
- Ajouter des détails précis sur la localisation du template MetalLB dans le répertoire Ansible.
- Expliciter la raison technique du conflit d'interface USB et des mesures préventives.
- Inclure un exemple concret de commande 'make apply-storage' pour valider la configuration.

**État réel connu de Hermes :**  
ok

---

## ✅ `admin/infra/email.md` — 8/10

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration du relais SMTP via Postfix vers Gmail, avec étapes claires et vérifications  

**Problèmes :**
- Les commandes 'make vault-edit' et 'make vault-encrypt' supposent l'existence de ces outils qui ne sont pas définis dans les dépôts
- Le paramètre 'require_tls: false' pourrait causer des problèmes de sécurité si Postfix ne gère pas le TLS correctement
- Aucune mention des règles SPF/DKIM pour les emails relayés, malgré la mention de Brevo

**Suggestions :**
- Ajouter une note explicite sur la validation des commandes 'make' avant exécution
- Mettre à jour la configuration pour utiliser TLS opportunément (require_tls: true avec le bon port)
- Inclure un exemple de règle SPF/DKIM pour les emails relayés vers Gmail

**État réel connu de Hermes :**  
ok

---

## ✅ `admin/infra/nfs.md` — 9/10

**Statut** : à_jour  
**Résumé** : Documentation complète et à jour sur la configuration NFS avec RAID5, exports, automounts et procédures d'extension  

**Problèmes :**
- Les options NFS ne spécifient pas de security=krb5 ou de squash pour les accès distants
- Manque de mention sur les quotas et politiques de stockage

**Suggestions :**
- Ajouter des notes sur la sécurité NFS (security=krb5, squash)
- Préciser les bonnes pratiques pour les quotas et les politiques de stockage

**État réel connu de Hermes :**  
Configuration stable avec deux exports actifs, automounts fonctionnels, et structure de répertoires cohérente

---

## ✅ `admin/infra/reseau.md` — 9/10

**Statut** : à_jour  
**Résumé** : Document complet sur la configuration réseau du homelab Funk, incluant interfaces, routes, nftables, ports ouverts et vérifications.  

**Problèmes :**
- La note sur l'ordre des règles nftables est succincte et pourrait être développée
- La colonne 'Source' dans le tableau des ports ouverts présente une syntaxe incohérente
- La section 'État vérifié' se termine abruptement avec un fragment incomplet ('llama-s')

**Suggestions :**
- Ajouter une section dédiée aux bonnes pratiques de débogage réseau
- Mettre en évidence les règles critiques avec des balises markdown
- Corriger la syntaxe des tables pour améliorer la lisibilité
- Ajouter des exemples concrets de scénarios de test

**État réel connu de Hermes :**  
Configuration réseau active avec tous les services mentionnés (LiteLLM, Qdrant, PostgreSQL, etc.). Les règles nftables sont gérées par Ansible. Il existe un fragment incomplet dans la section 'État vérifié' qui nécessite une vérification.

---

## ✅ `admin/infra/ssh.md` — 8/10

**Statut** : à_jour  
**Résumé** : Le document détaille les configurations SSH et les procédures de connexion/transfert, avec des exemples pratiques et un état vérifié récent.  

**Problèmes :**
- Manque de mention sur la rotation des clés SSH et la gestion des clés revocées
- Aucune information sur la sécurisation du jump host (s01) lui-même
- Les commandes de débogage pourraient inclure des cas d'usage plus variés (ex: erreurs de connexion, authentification)

**Suggestions :**
- Ajouter une section sur les bonnes pratiques de gestion des clés SSH (rotation, stockage sécurisé)
- Préciser les contrôles à effectuer sur le jump host (s01) pour garantir sa sécurité
- Compléter le débogage avec des exemples de résolution de problèmes spécifiques (ex: 'SSH: connexion refusée', 'clé refusée')

**État réel connu de Hermes :**  
Le serveur s01 a sshd actif sur le port 22 avec PermitRootLogin=yes et PasswordAuthentication=no. Les clés SSH sont configurées avec ed25519. Aucune anomalie critique détectée dans les configurations SSH.

---

