Re: Grosse fatigue
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.
Reply to: