Tu veux absolument avoir raison, je te laisse avoir raison. C'est tellement plus facile que de devoir remettre en cause des choix hasardeux.
Encore une fois, je ne t'ai pas attendu (d'autant qu'avant d'avoir posté la première fois ici, il y a quelques mois, j'ai filé le bébé aux développeurs de systemd, même avec un accès distant sur l'une des machines en défaut. La réponse fut "on ne sait pas ce qu'il se passe".). Au passage, avant de monter sur tes grands chevaux et de parler de fud, relis-moi bien attentivement. Parce que même en filtrant à peu près intelligemment la sortie d'auditd, c'est inapplicable sur des machines _diskless_ (je pense que c'est le mot que tu as sauté), sauf à savoir exactement ce que tu cherches. Mais là encore, tu as parfaitement raison, tout est théoriquement applicable. J'aimerais bien habiter en théorie, parce qu'en théorie, tout se passe bien. auditd _sature_ le serveur nfs, donc même si tu arrives à obtenir quelque chose, rien ne te dit que ce que tu auras obtenu sera pertinent parce que tu n'es plus dans les mêmes conditions de fonctionnement. Le simple fait d'activer auditd en filtrant intelligemment balance des "nfs server not responding" sur toutes les machines du réseau ! Tiens, sinon, histoire de rigoler et parce qu'on se dit tout, Debian n'est plus depuis au moins la version 11 avec systemd capable de tourner en diskless sur un serveur nfs (au moins V3/TCP conforme aux specs). Je te laisse installer une machine dans ces conditions parce que tu ne me croiras pas une fois de plus. Pourquoi ? Parce des attributs spéciaux (CAP_quelque chose) non compatibles nfs sont balancés aux disques (et comme par hasard, l'un des trucs qui gueule est justement systemd, d'où mes gros doutes sur les accès disques de ce truc). C'est bien de réinventer la roue, mais lorsqu'on n'est plus iso-fonctionnel ou que la roue est carrée parce c'est moderne, c'est un peu dommage. Je passe sous silence les autres choix merdiques qui ont été faits par des gens qui ne connaissent strictement rien en dehors de Linux ou qui s'en contrefichent (les algos de chiffrement par exemple, ce qui posé des problèmes aux serveurs de mails durant plus de deux ans (!), les formats des fichiers nis et j'en passe ! Mais il y a aussi l'inénarrable app-armor qui a de gros problèmes avec les configurations diskless.). Le système universel a du plomb dans l'aile parce qu'il n'arrive plus à fonctionner correctement qu'avec lui-même et, encore, seulement dans les configurations courantes ! J'en reste là. Certains membres de la communauté debian sont imbuvables et la conséquence est que le système lui-même part à vau l'eau dès qu'on n'est plus dans une configuration dite standard. C'est exactement comme ça qu'on se retrouve avec systemd et les autres concetés comme wayland et usrmerge. Ça fonctionne dans 99% des cas, il faut juste ne pas se retrouver dans les 1%. Et pour ta gouverne, le système fautif est un système pur debian/testing, réinstallé from scratch, avec un seul logiciel qui n'est pas issu des dépôts debian mais de Xilinx (et qui n'installe rien d'autre qu'un gros binaire dans /opt). D'ailleurs sans ce logiciel, ça merdoie exactement de la même façon. Ça merdoyait _aussi_ sur les autres debianeries diskless de la même façon après le passage de sysV vers systemd (voir l'un de mes premiers posts, raison pour laquelle j'ai réinstallé ces postes sous un autre OS). Ce n'est donc pas lié à une machine mais à la distribution et l'inénarrable systemd d'une manière ou d'une autre. Pas la peine de me répondre, je vais réinstaller cette machine sans systemd, je vais juste perdre deux ou trois jours pour la réinstaller (oui, deux ou trois jours parce c'est _diskless_ et rien que pour les modules du noyau, boost ou texlive, il y en a pour plusieurs _heures_ par paquet sur un serveur connecté au backbone à 2*5 Gbps). J'aurais dû faire ça depuis longtemps. Fin de la discussion.