Funk-lab/admin/hermes/builtin/2026-06-05_12-00.md

# Rapport Hermes — 2026-06-05_12-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é** : Documentation complète et structurée pour la configuration et la gestion de dnsmasq, avec des commandes clés et résolution de problèmes courants.  

**Problèmes :**
- Le chemin vers l'ansible-playbook (/mnt/nvme0n1/nvme0n1p3/Projets/lab/ansible) pourrait être obsolète si le dossier a été réorganisé
- Le problème du crash au démarrage lié à l'interface USB n'est pas résolu à long terme (solution temporaire fournie)

**Suggestions :**
- Ajouter une note sur la vérification des permissions pour les fichiers Ansible
- Mettre à jour le chemin vers le playbook si nécessaire
- Ajouter un exemple de vérification du statut de l'interface USB après démarrage

**État réel connu de Hermes :**  
dnsmasq fonctionne correctement avec la configuration actuelle. Le problème persistant lié à l'interface USB nécessite le fix permanent via le fichier de configuration systemd.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration du relais SMTP Postfix vers Gmail avec vérification et exemples d'utilisation, mais manque de détails sur l'état actuel du composant dans Funk  

**Problèmes :**
- Absence de section 'État réel' décrivant la configuration actuelle dans le homelab Funk
- Lien vers la configuration AlertManager est incomplet (fichier non affiché)
- L'exemple Python utilise '127.0.0.1' sans préciser le serveur SMTP réel

**Suggestions :**
- Ajouter une section 'État réel' avec vérification des paramètres actuels (postconf, sasl_passwd, generics)
- Compléter la configuration AlertManager avec des exemples de règles d'alerte
- Préciser l'adresse SMTP réelle dans l'exemple Python (ex: 'smtp.gmail.com')
- Ajouter une note sur la sécurité des App Passwords et leur rotation

**État réel connu de Hermes :**  
Le service Postfix est actif et fonctionne correctement selon les logs, mais la configuration exacte dans Funk n'est pas documentée ici

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète des configurations NFS avec des procédures claires, mais manque de détails sur la sécurité et les bonnes pratiques modernes.  

**Problèmes :**
- Le RAID md127 (4×1 TB) est décrit comme utilisant 2.7 TB utiles, mais cette valeur devrait être vérifiée avec 'df -h /srv/data' pour confirmer la capacité réelle
- Les options d'export NFS utilisent 'no_subtree_check' qui pourrait être obsolète ou moins sécurisé
- Le comportement automount n'indique pas les timeouts ou retries pour les cas de pannes réseau persistantes
- Aucune mention des règles de pare-feu ou des mécanismes de sécurité (KERBEROS, ACLs) pour les partages NFS

**Suggestions :**
- Ajouter une section sur les bonnes pratiques de sécurité pour NFS (chiffrement, quotas, ACLs)
- Mettre à jour les options d'export avec 'sec=krb5' si Kerberos est activé
- Inclure des exemples de vérification des permissions avec 'showmount -e 192.168.10.1'
- Ajouter une note sur les limitations des automounts lors d'updates système critiques

**État réel connu de Hermes :**  
Le système NFS est opérationnel avec les configurations décrites, mais des améliorations sécuritaires sont recommandées pour les environnements production

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration réseau du cluster Funk, avec des instructions claires pour nftables, routage et ports ouverts, mais nécessite quelques mises à jour pour les pratiques actuelles.  

**Problèmes :**
- La section nftables ne mentionne pas la gestion des règles avec nf-ovs ou les nouvelles fonctionnalités de nftables 1.9+
- Les exemples de commande nmcli pour les routes statiques utilisent 'enp12s0' qui pourrait être obsolète avec les nouvelles cartes réseau
- La configuration DNS ne précise pas la gestion des sous-réseaux via dnsmasq pour le LAN cluster
- Les règles de forwarding IPv4 ne mentionnent pas les considérations pour les conteneurs ou les réseaux virtuels

**Suggestions :**
- Ajouter une note sur l'utilisation de nft-ovs pour la gestion des ponts Open vSwitch
- Mettre à jour les exemples de commande avec les noms d'interfaces actuels du système
- Détaillez la configuration dnsmasq pour le LAN cluster avec /etc/dnsmasq.d/
- Ajouter une section sur la gestion des règles de forwarding pour les conteneurs (iptables -t nat)

**État réel connu de Hermes :**  
Le réseau fonctionne correctement avec nftables et les règles de forwarding, mais la documentation pourrait être mise à jour pour refléter les pratiques actuelles avec les conteneurs et les réseaux virtuels.

---

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

**Statut** : à_jour  
**Résumé** : Le document décrit correctement la configuration SSH du cluster avec des alias, transferts de fichiers et bonnes pratiques de sécurité (clés SSH, désactivation du mot de passe).  

**Problèmes :**
- Manque de mention sur l'utilisation du forward agent SSH
- Aucune information sur la rotation des clés SSH
- Le section 'État du serveur SSH' pourrait inclure la vérification de la version OpenSSH

**Suggestions :**
- Ajouter une note sur l'utilisation du SSH agent forwarding pour les connexions dédiées
- Mettre en avant la gestion des clés SSH pour GitHub/Bitbucket
- Ajouter un exemple de vérification de la version OpenSSH avec 'ssh -V'
- Suggérer l'utilisation de 'ssh-add' pour gérer les clés en mémoire

**État réel connu de Hermes :**  
SSH configuré avec authentification par clé, désactivation de PasswordAuthentication, aliases fonctionnels pour les machines du cluster. Les paramètres critiques (PermitRootLogin, PubkeyAuthentication) sont correctement activés.

---