[Resolved] Erreur de diagnostique - connectivité

:fr:

Mon serveur YunoHost

Matériel: VPS acheté en ligne
Version de YunoHost: 4.3.6.2
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

Hello,
Rien de grave (je crois), mais j’ai eu sur deux serveurs différents des erreurs bizarres dans le diagnostique. C’est pas catastrophique, mais quand on reçoit des mails avec des erreurs, je passe parfois des heures à essayer de comprendre ce qui arrive, pour constater qu’apparemment, il n’y a rien…

J’ai eu par exemple ce problème de diagnostique :


Vous remarquerez que je consulte le diagnostique par la webadmin, ce qui veut dire que le serveur est accessible en ligne, que son ipv4 fonctionne !

Au bout de quelques heures, sans rien trouver de problématique, je retourne sur le diagnostique, et l’erreur a disparu. Je n’ai rien changé.

Une autre erreur, difficile à cerner :
le diagnostique :

+ Le port 25 est accessible de l'extérieur.
- Le port sortant 25 semble être bloqué. Vous devriez essayer de le débloquer dans le panneau de configuration de votre fournisseur de services Internet (ou hébergeur). En attendant, le serveur ne pourra pas envoyer des emails à d'autres serveurs.

Si je fais netstat -tulnp, j’ai bien :

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      3412/master
tcp6       0      0 :::25                   :::*                    LISTEN      3412/master

J’ai regardé du côté d’OVH (ici et ), apparemment, si notre serveur est considéré comme envoyant du spam, le port 25 sortant est bloqué. J’ai essayé diverses choses, lu les mail.log, rien trouvé de bizarre.

J’avais fait un test il y a quelques jours en mettant le cron de wordpress sur */5 * * * *, pour voir comment se comportait un plugin avec une mise à jour toutes les 5 minutes.
Dans les mail.log, je retrouve un mail toutes les 5 minutes. C’est peut-être de là que vient le problème ? Je suis donc repassé à un toutes les 3 h (0 */3 * * * ). Aujourd’hui, en voulant poursuivre mes investigations, je refais un diagnostique, et l’erreur est partie (peut-être qu’OVH a réouvert le port sortant, je ne sais pas).
Pour ce second problème, je ne suis pas sûr que le diagnostique se plante, du coup c’est difficile de savoir où chercher. Existe-t-il une commande pour vérifier si les ports sortants sont ouverts ? J’ai l’impression que netstat ne donne que les ports entrants.

Si effectivement des spams sortent de mon serveur sans que je le vois, ça peut être assez grave…

J’ai aussi des erreurs de connectivité Diagnosis sur 2 serveurs différents depuis quelques jours, un sur un serveur dédié, l’autre sur un serveur auto-hébergé avec VPN… Je suspecte plutôt une erreur du Diagnostique…

Même alerte sur l’absence d’adresse IPV4 sur mon serveur hier soir, et aujourd’hui un problème d’enregistrements DNS

Pour cette partie, ça peut arriver si il y a eu une surcharge ou une maintenance sur l’infra YunoHost.

Ok @ljf est-ce que pour les mails; c’est valable aussi ?

J’ai revérifié ce matin : malgré mon changement de cron pour wordpress, j’ai toujours des envois en postfix toutes les 5 minutes, qui se présentent ainsi :

Mar  7 06:55:01 monserveur postfix/pickup[6045]: 6459581253: uid=33 from=<www-data>
Mar  7 06:55:01 monserveur postfix/cleanup[21281]: 6459581253: message-id=<20220307065501.6459581253@monserveur.fr>
Mar  7 06:55:01 monserveur postfix/qmgr[3414]: 6459581253: from=<www-data@monserveur.fr>, size=938, nrcpt=1 (queue active)
Mar  7 06:55:01 monserveur postfix/pipe[21286]: 6459581253: to=<www-data@monserveur.fr>, orig_to=<www-data>, relay=dovecot, delay=0.07, delays=0.03/0.01/0/0.03, dsn=5.1.1, status=bounced (user unknown)
Mar  7 06:55:01 monserveur postsrsd[21284]: srs_forward: <""> not rewritten: No at sign in sender address
Mar  7 06:55:01 monserveur postfix/cleanup[21281]: 733F08158A: message-id=<20220307065501.733F08158A@monserveur.fr>
Mar  7 06:55:01 monserveur postfix/qmgr[3414]: 733F08158A: from=<>, size=2942, nrcpt=1 (queue active)
Mar  7 06:55:01 monserveur postfix/bounce[21289]: 6459581253: sender non-delivery notification: 733F08158A
Mar  7 06:55:01 monserveur postfix/qmgr[3414]: 6459581253: removed
Mar  7 06:55:06 monserveur postfix/pipe[21286]: 733F08158A: to=<www-data@monserveur.fr>, relay=dovecot, delay=5, delays=0.01/5/0/0.01, dsn=5.1.1, status=bounced (user unknown)
Mar  7 06:55:06 monserveur postfix/qmgr[3414]: 733F08158A: removed

Mais j’ai aussi, tous les jours à 7h, ceci :

Mar  6 07:00:30 monserveur dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=80.67.172.144, lip=193.70.115.28, TLS handshaking: Connection closed, session=<ViStTYfZQLNQQ6yQ>
Mar  6 07:00:30 monserveur postfix/smtpd[10457]: connect from yunohost.org[80.67.172.144]
Mar  6 07:00:30 monserveur postfix/submission/smtpd[10459]: connect from yunohost.org[80.67.172.144]
Mar  6 07:00:30 monserveur postfix/submission/smtpd[10459]: lost connection after CONNECT from yunohost.org[80.67.172.144]
Mar  6 07:00:30 monserveur postfix/submission/smtpd[10459]: disconnect from yunohost.org[80.67.172.144] commands=0/0
Mar  6 07:00:30 monserveur postfix/smtpd[10457]: lost connection after CONNECT from yunohost.org[80.67.172.144]
Mar  6 07:00:30 monserveur postfix/smtpd[10457]: disconnect from yunohost.org[80.67.172.144] commands=0/0
Mar  6 07:00:30 monserveur dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=2001:910:1410::1, lip=2001:41d0:401:3200::3747, TLS handshaking: Connection closed, session=<34iwTYfZ5tAgAQkQFBAAAAAAAAAAAAAB>
Mar  6 07:00:30 monserveur postfix/smtpd[10457]: connect from yunohost.org[2001:910:1410::1]
Mar  6 07:00:30 monserveur postfix/smtpd[10457]: lost connection after CONNECT from yunohost.org[2001:910:1410::1]
Mar  6 07:00:30 monserveur postfix/smtpd[10457]: disconnect from yunohost.org[2001:910:1410::1] commands=0/0
Mar  6 07:00:30 monserveur postfix/submission/smtpd[10459]: connect from yunohost.org[2001:910:1410::1]
Mar  6 07:00:30 monserveur postfix/submission/smtpd[10459]: lost connection after CONNECT from yunohost.org[2001:910:1410::1]
Mar  6 07:00:30 monserveur postfix/submission/smtpd[10459]: disconnect from yunohost.org[2001:910:1410::1] commands=0/0
Mar  6 07:00:31 monserveur postfix/smtpd[10457]: connect from yunohost.org[80.67.172.144]
Mar  6 07:00:31 monserveur postfix/smtpd[10457]: lost connection after CONNECT from yunohost.org[80.67.172.144]
Mar  6 07:00:31 monserveur postfix/smtpd[10457]: disconnect from yunohost.org[80.67.172.144] commands=0/0
Mar  6 07:00:31 monserveur postfix/smtpd[10457]: connect from yunohost.org[2001:910:1410::1]
Mar  6 07:00:31 monserveur postfix/smtpd[10457]: lost connection after CONNECT from yunohost.org[2001:910:1410::1]
Mar  6 07:00:31 monserveur postfix/smtpd[10457]: disconnect from yunohost.org[2001:910:1410::1] commands=0/0
Mar  6 07:03:51 monserveur postfix/anvil[10461]: statistics: max connection rate 2/60s for (smtp:80.67.172.144) at Mar  6 07:00:31
Mar  6 07:03:51 monserveur postfix/anvil[10461]: statistics: max connection count 1 for (smtp:80.67.172.144) at Mar  6 07:00:30
Mar  6 07:03:51 monserveur postfix/anvil[10461]: statistics: max cache size 4 at Mar  6 07:00:30

Est-ce normal d’avoir autant d’envois ? Qu’est censé envoyer www-data ?

1 Like

Pour la 2ème partie c’est ton diagnostique qui se lance à 7h et demande au diagnostique distant de tester l’ouverture des ports mails.

Pour les mails toutes les 5 min à www-data, c’est moins clair, il est possible qu’une app essaie d’envoyer un mail à cette adresse vers ton serveur. Si tu veux savoir ce que c’est faut ajouter l’alias www-data@monseveur.fr sur ton utilisateur yunohost principal (celui qui a déjà les alias root@ abuse@ …)

1 Like

Gagné !!
La réponse se trouvait dans le mail :
sujet :

Cron <www-data@monserveur> php7.3 --define apc.enable_cli=1 -f /var/www/nextcloud/cron.php

Corps :

Cannot write into "config" directory!
This can usually be fixed by giving the webserver write access to the config directory.

But, if you prefer to keep config.php file read only, set the option "config_is_read_only" to true in it.
See https://docs.nextcloud.com/server/22/go.php?to=admin-config

C’était bien lié à un cron, mais pas celui de wordpress, celui de nextcloud…
Ceci dit, je suis surpris de cette erreur : Je suis allé voir dans /etc/cron.d/nextcloud, j’ai ça :

*/15  *  *  *  * nextcloud /usr/bin/php7.3 --define apc.enable_cli=1 -f /var/www/nextcloud/cron.php

Étonnant du coup d’avoir des envois toutes les 5 minutes…
Alors je me suis dit que j’avais peu-être fait une modif il y a longtemps, ailleurs…
la commande crontab -u www-data -l m’a aidé : effectivement, j’ai bien un cron modifié ici :

*/5 * * * * php7.3 --define apc.enable_cli=1 -f /var/www/nextcloud/cron.php

Je l’ai enlevée (crontab -u www-data -e), plus de mails.

J’ai vérifié dans nextcloud, les tâches cron sont toujours effectuées. J’avais bien fait une bourde !

Morale de l’histoire :

:warning: :warning: :warning: Les commandes qu’on trouve sur internet pour gérer un debian ne fonctionnent pas toutes comme on le voudrait. En l’occurrence, vouloir gérer les tâches cron avec la commande crontab -u www-data -l ne modifie pas le fichier /etc/cron.d/nextcloud, mais un autre je ne sais où. Les deux sont lus, mais l’user www-data n’ayant pas les droits nécessaires pour s’exécuter correctement, ça plantait. Et dans mon cas, ça plantait toutes les 5 minutes… spamhaus m’avait blacklisté, je comprends mieux pourquoi…

Merci de ton aide @ljf :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.