Analysés : dnsmasq.md, email.md, nfs.md, reseau.md, ssh.md À améliorer : 0/5 Co-Authored-By: Hermes <hermes@funk.lab>
5.9 KiB
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.