Mails quotidiens de diagnostique

Hello les yunohosteurs, depuis la derniere mise à jour, je recois des mails de diagnostique. C’est super, cependant il y a des conseils au niveau DNS et MX que je ne partage pas par exemple :
[ERROR] Some DNS records are missing or incorrect for domain domain.tld (category mail)

  • Please check the documentation at https://yunohost.org/dns_config if you need help about configuring DNS records.
  • The following DNS record does not seem to follow the recommended configuration:
    Type: TXT
    Name: @
    Current value: “v=spf1 a mx +ip4:xxx.xxx.xxx.xxx/32 -all”
    Excepted value: “v=spf1 a mx -all”
  • The following DNS record does not seem to follow the recommended configuration:
    Type: TXT
    Name: _dmarc
    Current value: “v=DMARC1; p=quarantine; rua=mailto:admin@domain.tld; ruf=mailto:admin@domain.tld; fo=1; adkim=s; aspf=s; pct=100; rf=afrf; ri=86400; sp=quarantine”
    Excepted value: “v=DMARC1; p=none”

Au niveau du certificat j’ai ça :

  • The following DNS record does not seem to follow the recommended configuration:
    Type: CAA
    Name: @
    Current value: [u’0 iodef “mailto:[admin@domain.tld](mailto:admin@domain.tld)”’, u’0 issue “letsencrypt.org”’, u’0 issuewild “;”’]
    Excepted value: 128 issue “letsencrypt.org
    J’ai aussi ça :
    Domain domain.tld appears unreachable through HTTP from outside the local network.
  • It looks like another machine (maybe your internet router) answered instead of your server.
  1. The most common cause for this issue is that port 80 (and 443) are not correctly forwarded to your server.
  2. On more complex setups: make sure that no firewall or reverse-proxy is interfering.

Mon serveur Yunohost tourne dans un conteneur lxc depuis plus de deux ans sans aucun probleme :slight_smile:

Ca aussi forcement puisque je passe par un bastion ssh :slight_smile:
Port 22 is not reachable from outside.

Comment fait-on pour modifier les critères d’audit ?

Merci et @ bientôt

A part modifier le code (qui sera réécrit à chaque upgrade) tu ne peux pas … mais ici le soucis c’est plutôt que tu es dans un setup avancé (genre customisation des DNS) qui ne corresponds pas aux bidouilles légitimes que tu fais, donc la recommendation c’est juste d’ignorer les checks correspondants (en supposant que tu sais ce que tu fais)

Par contre le fait qu’il te dise que ton serveur n’a pas l’air contactable depuis l’extérieur c’est étrange / pas normal si il l’est effectivement. À moins que tu sois derrière un reverse proxy qui ne reverse-proxy pas le port 80.

Salut Aleks, ça fait longtemps !! Oui je sais ce que je fais pour le MX :).
Je suis sur un hyperviseur derriere un firewall et j’ai configuré une IP publique virtuelle qui tape directement sur le LXC.

Et peut-on régler la fréquence de ce rappel ?

J’en reçois 3 par jours actuellement (3 serveurs), c’est assez pénible vu que ce connais le contenu du diagnostic, mais que je ne m’en occuperait pas pour le moment ou pas du tout pour certains enregistrement DNS (par exemple pour le mail).
Et ça fait beaucoup de mail envoyés pour rien :frowning:

@Lapineige : tu peux bricoler la frequence du cron qui doit se trouver dans /etc/cron.d/ (genre yunohost-diagnosis, pas sur du nom)

Mais en effet, l’idée du diagnostique c’est tout de même un peu que soit tu règles les soucis, soit tu sais ce que tu fais et donc tu ignores le check… Et que donc ton serveur est “green” par défaut, et que le jour où il y a un soucis, tu recevras un mail qui t’averti du truc…

Sinon tu tombes effectivement dans le truc contre-productif des outils de monitoring où ça t’envoie tellement d’alerte tout le temps que tu fini par ignorer les messages et donc t’es pas au courant le jour où y’a un vrai soucis …

Question, sur quelle adresse le rapport est-il envoyé ?

root@maindomain.tld, qui est un alias vers le premier user que tu as créé normalement…

Bonjour @Aleks,

Bon le truc c’est que j’ai changé le domaine par défaut une ou deux fois et que j’ai “harmonisé” les adresses mails (je t’endends penser :pleading_face:). Sans compter que j’ai créé un sous-domaine juste pour les mails pour que ce soit plus joli :star_struck: et du coup toutes les adresses des users (en réalité il n’y a que la mienne qui compte pour que le serveur puisse communiquer avec moi) sont configurées sur ce sous-domaine pas par défaut. A pu d’adresses sur le domaine par défaut :grimacing:

On était jeunes lui et moi, on ne savait pas ce qu’on faisait… :nerd_face:

Comment puis-je lister les adresses mails configurées sur le serveur ?

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.