Mails quotidiens de diagnostique

Justement, le problème est que les problèmes signalés je ne compte pas les résoudre, car ce n’est rien de problématique pour moi.
Et pour certain, honnêtement je ne comprends pas grand chose à ce qu’il faut faire comme enregistrement DNS, comme ça marche je n’ai pas trop envie d’y toucher… à part pour éviter les 3 messages/jour :laughing:

J’ai ça avec netdata, sur le raspberry pi faut absolument baisser toutes les alertes par défaut à un seuil de sensibilité beaucoup plus bas :sweat_smile: (et c’est long et chiant à faire).


edit: d’ailleurs l’affichage des enregistrements DNS qu’il faut faire c’est vachement pratique, même si je ne les trouve pas super parlant (et j’aimerais bien avec juste le DNS en format texte à copier-coller dans mon interface ^^), mais si je peux suggérer une amélioration, expliquer à quoi sert tel ou tel enregistrement ça aiderait beaucoup à comprendre et le problème et à quoi ça sert de faire ça, et à apprendre (un peu) comment fonctionne le DNS. Mais j’imagine que y’a déjà eu pas mal de boulot sur cette fonction :slight_smile:

1 Like

Bonjour @Lapineige,

Tu trouveras peut-être certaines infos sur la page d’aide (YunoHost • index).

Attention que YH ne fait pas (encore) la différence entre la racine (domaine.tld) et un sous-domaine. Dès lors, la configuration proposée par YH n’est pas exacte dans le cas d’un sous-domaine.

Par exemple :

@ 3600 IN MX 10 votre.domaine.tld.

N’est pas correct et il faut remplacer le @ (racine ou apex) par le sous-domaine.

Configurations avancées pour les mails (et compréhension des dns en général) :

Certes, mais je n’y comprends toujours pas grand chose, et un simple copier-coller n’est pas toujours possible/efficace :sweat_smile:

J’ai réussi à faire marcher mes serveurs sans faire grand chose, y compris pour l’envoi de mail via des sous-domaine (pourtant le diagnostic me dit que ce n’est pas bon :thinking:), mais pas plus ^^

Merci des infos !
(Donc le @ concerne le domaine principal ? edit: ah ben c’est écrit dans la doc’, m’en souvenait plus ^^)

Je n’y comprends pas grand chose non plus. Ces enregistrements sont des informations sur la manière dont le dns doit gérer les domaines / sous-domaines, quant aux protocoles derrières tout ça, c’est encore une autre histoire.

Mais tu peux ignorer les “erreurs” pour les domaines pour lesquels tu n’as pas besoin de ces configurations.

Au-delà de ce “problème” d’indifférenciation entre domaine et sous-domaine, la configuration proposée par YH est d’une grande aide.

Oui c’est bien ça.

Pour moi c’est pareil, je reçois des e-mails me demandant de mettre un champ CAA pour mes dns, mais chez mon registrar je ne peux pas ajouter un champ CAA à moins de prendre une autre formule, + chère, ou de passer par cloudfare… Donc je reçois des e-mails à ce sujet ce qui est un peu gênant si j’en reçois plusieurs par jour pendant x mois/années…

Le fichier à modifier est celui-là nano /etc/cron.d/yunohost-diagnosis.

Actuellement la valeur de fréquence est à : 0 7,19 * * * Soit deux exécutions par jour, à 7 et 19h. (pourquoi autant ? :astonished:)

Pour l’instant j’ai mis 0 0 * * 6 (une fois par semaine, le samedi à minuit), peut-être que je vais passer à une fois par mois si c’est trop embêtant :thinking:

PS: j’ai utilisé ça https://crontab.guru/ parce que je ne comprends jamais rien aux réglage de cron ^^

2 Likes

Effectivement ça aide bien sinon on serait complètement perdu⋅es pour la plupart :sweat_smile:

Je n’avais pas compris qu’il manquait des infos pour les sous-domaines (pourquoi ?), c’est assez embêtant.
Par exemple là j’essaye de corriger l’erreur de DNS pour le mail, et j’ai bien rajouté mail._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=uneGrannnnndeClef" comme demandé par la doc’, mais ça ne marche pas. Est-ce qu’il faut changer des choses pour le sous-domaine ? (sousdomaine.mail._domainkey, un truc comme ça ?)

Dans ce cas, comme le bandeau d’information tout en haut de l’interface de diagnostique explique : le bouton ignore est fait pour ça …

Pareil, bouton ignore.

Ben uh figure toi que c’est pas beaucoup … si il y a un problème majeur sur ton serveur tu peux avoir envie d’être averti le plus rapidement possible, et certains ont des système de monitoring qui tournent toutes les 5~10 minutes… Mais après c’est toi qui voit et il y a pleins de contexte différent. Encore une fois, si t’as des messages d’alertes qui n’ont pas de sens et que tu sais ce que tu fais et/ou ne compte pas les corriger, tu cliques sur Ignorer.

1 Like

Ça, je ne sais pas. Je pense que les dev prévoient d’améliorer cet aspect (meilleure gestion des domaines), si j’ai bien compris.

Oui, tu dois modifier comme suit :

mail._domainkey.sous-domaine 3600 IN TXT "v=DKIM1; k=rsa; p=uneGrannnnndeClef"

Ah !
Je ne savais pas qu’il y avait ça. J’ai reçu tout par mail, et après j’ai utilisé la ligne de commande, je n’ai pas vu ces messages.
Ça les ignorera définitivement ?
Ça m’intéresserait de continuer à en voir certains, mais sans recevoir d’alerte.

C’est juste, et du coup ça détecte ce genre de problème ? Comme il ne me donnait des erreurs que pour le DNS (et je n’ai pas de problème d’usage lié à ces enregistrements), je n’avais pas l’impression que c’était le cas. Y’a des éléments du type la charge du serveur ?

Pour le coup j’ai déjà netdata (qui me spam de mail :laughing:) et grafana, donc pas besoin de ça a priori, je vais garder une fréquence basse, ça servira si je touche au DNS à détecter une erreur.

Aaaaaaah merci, je n’aurais pas pensé que c’était comme ça qu’il fallait faire ^^
(fin du HS)

Non tu peux cliquer “Désignorer” ensuite … Ils seront toujours affichés mais en grisé

Oui et non, y’a l’utilisation de la RAM et du disque mais pas le CPU. Mais y’a aussi toute sorte de check sur est-ce que les services sont up, est-ce que ton domaine ne va pas expirer, est-ce que y’a pas un soucis dans la stack mail, etc… Et puis surtout tout ça est amené à avoir des trucs en plus (c.f. cette wishlist)

Excellent, et merci de l’info :slight_smile:

Ok, c’est déjà pas mal, et y’a plein de cas particuliers auxquels on ne penserait pas initialement (ce qui est top). Merci des infos.

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é :slight_smile:
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 :slight_smile:
Ç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 :slight_smile:

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 ?