Comme expliqué, le plus simple est d’aller dans Web Admin > Diagnostique et de cliquer sur ignorer lorsque tu penses que quelque chose n’est pas pertinent dans ton cas.
Bonjour à vous,
Savez-vous comment ignorer le diagnostique d’un service en ligne de commande?
Pour des raisons de sécurité je désactive l’API de Yunohost mais, une fois fait, le diagnostique me dit que le service API est “dead” et évidemment je ne peux pas aller dans le web admin pour ignorer ce service.
Tu peux regarder ici pour l’explication :
sachant que tu peux avoir les meta-data qui caracterise un test avec yunohost diagnosis show --issues --full (c.f. la clef “meta”)
Il y a quelque chose qui me dérange dans le concept du diagnostique. Peut-être que c’est parce que j’ai soudain reçu des messages dans ma boîte mail privée alors que je n’avais rien demandé 
Mais j’aime bien l’idée de fond, c’est super. Par contre, j’aime aussi l’idée que si je veux un diagnostique de mon serveur, je vais être un peu acteur. Par ex : openscap. On va installer le rpm et on fait ensuite les tests sur le système (et redhat nous propose les scripts pour colmater les brèches). Pourquoi ne pas en avoir fait une application plutôt que de l’avoir integrée au “système”.
Je pense que le diagnostique ne devrait pas aller jusqu’à checker la configuration DNS. La syntaxe des services DNS n’est pas toujours tout à fait la même il me semble : certains auront bind, d’autres nsd, parfois Knot… D’autres encore (une majorité) n’auront accès qu’aux services limités de leurs hébergeurs. Peut-être qu’on pourrait imaginer deux ou trois niveaux de diagnostique ? Genre un en mode INFO, l’autre VERBOSE et peut être un FULL. @ljf merci, c’est ce que j’ai fait.
Tu peux tout ignorer pour qu’il ne s’active plus pour toi si tu le souhaite
Ça reste très utile pour une bonne partie des personnes utilisants Yunohost, sans forcément de compétences importantes en informatique, et qui ne penseront pas forcément à installer ce genre d’outil, et ne verront pas tous les problèmes signalés par cet outil.
Les personnes avec un usage plus avancé peuvent s’en passer pour utiliser l’outil qu’elles préfèrent.
Yes, d’où ma remarque si j’ignore tout pourquoi avoir ça sur mon système ? Ensuite vu les commentaires ceux moins avancés n’iront pas forcément bidouiller pour changer leurs confs. Cet outil intéressant s’adresse à ceux qui sont moyennement avancés dans l’apprentissage des systèmes. Bon je n’ai pas envie de rentrer dans une polémique surtout que je ne bosse pas sur le système yunohost
En même temps ça permettra à ces “novices” de comprendre qu’il y a un potentiel soucis, potentiellement de les alerter avant qu’il n’y ai des dégâts trop important. Le détail est censé aider à la résolution du problème mais c’est sûr qu’il y a probablement encore du chemin à faire sur ce point.
Sur l’email typiquement c’est très compliqué d’avoir une configuration viable et ça peut évoluer dans le temps avec les fournisseurs qui activent ipv6 sans crier gare ou les FAI qui désactivent le reverse DNS ou autre…
Par ailleurs, ce système devrait permettre de limiter certaines questions de supports ou de les résoudre plus rapidement.
Pour l’histoire de la conf DNS, il y a pas mal de retour à ce sujet, mais certaines fausses alertes sont plus liées à un défaut dans la gestion des sous-domaines et à l’absence de paramètres de domaine permettant par exemple de désactiver le mail ou xmpp sur tel ou tel domaine. A mon sens c’est quelques choses qui tendra à disparaître. Le logiciel qui fait tourner le DNS ne change rien car à la fin une requête avec dig donne le même résultat.
Ceci dit je suis d’accord que le comportement actuel n’est pas optimal.
Par ailleurs, l’outil de diagnostique est utilisé pour améliorer certaines fonctionnalités comme la mise en place de Let’s Encrypt, l’ancien système de détection d’ouverture de port était moins fiable (notamment avec les personnes configurant des reverse proxy. Il me semble aussi que c’est ou sera utilisé pour optimiser certaines opérations nécessitant un diagnostique de la connectivité.
Enfin les apps pouvant ajouter des tests aux diagnostiques et les tests étant construits spécifiquement pour YunoHost, cet outil devrait permettre de contrôler au delà de ce que pourrait contrôler un outil standard (à moins de passer énormément de temps à le configurer). Cette fonctionnalité aurait été complexe à gérer si l’outil n’avait pas été intégré.
Ceci dit on peut imaginer qu’un paramètre soit disponible pour adapter la fréquence du diagnostique, voir pour le désactiver partiellement.
Je me permets d’apporter mes 2 centimes sur ce fil, comme j’ai également commencé à être un peu spammé depuis la dernière mise à jour. Je comprends parfaitement l’usage et je l’apprécie, ça m’a d’ailleurs aidé à résoudre 2 petites pétouilles sans importances. En particulier le check au sein des listes d’exclusion des serveurs mails est géniale ! Merci beaucoup à toute l’équipe pour tout le travail effectué !
Cependant, je suis comme certains dans ce fil un peu embêté par l’approche « tout ou rien ». Par exemple, suite à diverses lectures à droites et à gauche, j’ai généré une clé dh_param pour mon serveur. Du coup j’ai défait le commentaire autour de la ligne ssl_dhparam /etc/ssl/private/dh2048.pem; du fichier /etc/nginx/conf.d/security.conf.inc. Depuis l’outil de diagnostique me remonte ce fichier en erreur. Or je ne veux pas non plus l’ignorer complètement, car un autre écart dans ce fichier (suite à une prochaine mise à jour par exemple) sera peut-être important à corriger.
Serait-il de ce fait envisageable d’imaginer un mécanisme d’ignorance temporaire, qui sauterait à la mise à jour suivante ? Je veux dire, j’aimerai pouvoir dire à l’outil de diagnostique « ok j’ai compris pour ça, mais ignore cette erreur jusqu’à la prochaine exécution de regenconf ».
Ou alors ajouter un système de versionnage des recommandations. Par exemple j’ai le même souci « d’erreur » dans les champs DNS, lié au fait que j’ai mis en place une config custom de DMARC. J’aimerai pouvoir ignorer la recommandation actuelle (Expected value: "v=DMARC1; p=none"), mais si jamais cette dernière évoluait, je serais très intéressé de connaître sa nouvelle version.
Je m’inquiète également du devenir de ces listes d’ignorance. Est-il possible à terme par exemple que regenconf se base sur ces liste d’ignorance pour ne même plus nous alerter des fichiers modifiés lors des mises à jour ? Ou les deux applications (diagnosis et regenconf) resteront bien séparée ? Si regenconf utilisait la liste d’ignorance de diagnosis, ce serait une erreur à mon sens, car je continue de fusionner à chaque mise à jour les changements amont avec mes propres changements. Perdre cette information de changement parce que j’ai ignoré une recommandation serait très dommageable.
Bref, pour l’instant je me retrouve avec une longue liste de fichier/règles ignorés, que je vais sans doute manuellement supprimer lors de ma prochaine mise à jour pour les comparer à nouveau, avant possiblement de les ignorer à nouveau si les recommandations n’ont pas changées. Du coup un peu plus de finesse dans la gestion de ces erreurs serait la bienvenue.
Qu’en pensez-vous ?
Yep, ce n’est pas ce qui est prévu
Mokay mais cliquer sur ignore ça ne dit pas que tu ne pourras pas avoir l’info, ça veut juste dire que ce n’est pas considérer comme une erreur parce que tu sais ce que tu fais (ou que le test n’est pas pertinent dans ton cas). Je vois pas dans quelle mesure ça t’empêche de re-vérifier à chaque mise à jour … Note que tu n’as pas besoin d’ignorer/désignorer les trucs pour regarder le diff de la regenconf…
Le truc c’est que dans de nombreux cas, pleins de gens oublient qu’ils ont modifié un fichier (ou alors un autre truc s’est passé qui a modifier le fichier) et au moins le diagnostique rend cela bien visible.
Yep… l’imagine c’est une chose mais ensuite il faut le faire et voir si la complexité en vaut la chandelle (dans le cas présent, ça ne devrait pas être trop compliqué)
1 Like
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.