Erreurs suite mise à jour en 3.8

Mon serveur YunoHost

Matériel: Raspberry Pi à la maison
Version de YunoHost: 3.8.4.3
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : oui
Modifications des fichiers Nginx. Tentative d’un regen-conf sans succès.

Bonjour,

J’ai plusieurs erreurs dans la section diagnostic dont:

Le serveur ne dispose pas d’une adresse IPv4
Certains enregistrements DNS sont manquants ou incorrects (xmpp et extra)

J’ai tenté yunohost dyndns update mais la mise à jour ne se fait pas avec le message d’erreur suivant:

Communication with 80.67.172.144#53 failed: operation canceled
dns_request_createvia3: not implemented
Info : L’opération 'Mettre à jour l’adresse IP associée à votre sous-domaine YunoHost 'domain.tld'' a échoué
Erreur : Impossible de mettre à jour l’adresse IP sur le domaine DynDNS.

C’est arrivé avec la mise à jour en 3.8. Je l’ai faîte dès son annonce le 20 mai en ligne de commande et il ne s’est apparemment rien passé sauf une indication du numéro de la montée de version en 3.8. J’ai relancé peu de temps après et là la maj s’est bien faite avec toutes les nouveautés dans la webadmin.

Apparemment plus rien concernant yunohost n’est joignable, d’ailleurs j’ai également cette erreur dans le diagnostique: Le serveur ne dispose pas d’une adresse IPv4.
Une mise à jour me retourne par exemple:

Attention : W: Failed to fetch http://forge.yunohost.org/debian/dists/stretch/InRelease Could not connect to forge.yunohost.org:80 (80.67.172.144), connection timed out

Et également
Erreur : Impossible de télécharger le catalogue des applications default : URL https://app.yunohost.org/default/v2/apps.json invalide : ce site existe-t-il ?

Moi qui venait de vanter les mérites de yunohost qui ne tombait jamais en panne, j’ai perdu l’occasion de me taire! :crazy_face:

Le problème vient-il de chez moi ou y-a-t-il une possibilité de réparer avant de tenter une restauration? Est-ce qu’une restauration des fichiers système sera suffisante pour ce cas là?

Wokay ben c’est chelou … J’imagine que ça pourrait être juste un bug dans le diagnostique mais les autres symptomes semblent concorder vers un soucis de connectivité quand même …

Mais bon j’imagine que si tu fais des trucs en CLI c’est via SSH et que donc la machine a bien une IP ?

Si tu fais un ping -c1 wikipedia.org est-ce que ça fonctionne ?

Salut @Aleks,

Oui, je suis en SSH mais à partir du réseau local et la machine a bien une adresse ip, elle est vu sur le réseau quand je lance la commande arp-scan --local. Le ping a bien l’air de répondre:

ping -c1 wikipedia.org
PING wikipedia.org (91.198.174.192) 56(84) bytes of data.
64 bytes from text-lb.esams.wikimedia.org (91.198.174.192): icmp_seq=1 ttl=60 time=113 ms

--- wikipedia.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 113.381/113.381/113.381/0.000 ms

En complément d’infos, j’ai tenté un ping dyndns.yunohost.org et ça répond bien. Par contre un curl “https://dyndns.yunohost.org lui ne fonctionne pas alors que l’adresse est bien joignable à partir de mon PC avec firefox.
J’ai tenté un curl sur une adresse quelconque et ça fonctionne, par contre impossible avec n’importe quelle page en rapport avec yunohost, j’ai tenté curl yunohost.org/ et ça ne répond pas non plus, je ne récupère pas la page. Le problème a l’air de se produire qu’avec yunohost.org.

Désolé du dérangement, c’est certainement en rapport avec ça:

J’ai un filtre Fail2ban postfix-auth, et les mails provenant de yunohost tombaient dedans je suppose à cause des problèmes d’infrastructure, en tout cas ça correspond au vu de la date:

May 21 12:16:28 metyun postfix/submission/smtpd[8772]: connect from yunohost.org[80.67.172.144]
May 21 12:16:28 metyun postfix/submission/smtpd[8772]: lost connection after CONNECT from yunohost.org[80.67.172.144]

Et ça a fini par tomber dans le filtre Recidive.
Tout fonctionne maintenant après un fail2ban-client set recidive unbanip 80.67.172.144

@Aleks : Finalement, toujours le problème, l’ip se fait bannir, une idée de quoi ça pourrait venir? C’est apparu le 21 mai après que j’ai mis à jour en 3.8, je n’avais pas le souci avant avec le même filtre. Je vais mettre une exception pour contourner mais j’aimerais bien comprendre d’où ça peut venir:

May 24 19:03:28 metyun postfix/submission/smtpd\[16784\]: lost connection after CONNECT from yunohost.org\[80.67.172.144\]
May 24 19:03:32 metyun postfix/smtpd\[16790\]: lost connection after CONNECT from yunohost.org\[80.67.172.144\]
May 24 19:04:03 metyun postfix/smtpd\[16790\]: lost connection after CONNECT from yunohost.org\[80.67.172.144\]

Bonsoir @tous
@metyun tu n’as pas portsentry installé sur ton serveur j’ai eu le même messages de diagnostics que toi après la mise à jour 3.8.

Du coup j’ai remis la configuration recommandée de yunohost, et là c’est le drame plus de connexions.
Je ne l’avais pas remarqué avant car j’avais modifié mon fichier /etc/resolv.dnsmasq.conf
pour ajouter l’ip de mon routeur netgear r8000 sous freshtomato pour profiter de son adblock intégré.

Portsentry avait blacklisté les ip du fichier /etc/resolv.dnsmasq.conf, du coup j’ai du mettre ces ip dans le fichier /etc/portsentry/portsentry.ignore.static pour ne pas me faire insulter par diagnostics :wink:

J’espère t’avoir donné uns piste pour solutionner ton problème.

Merci @mib,
oui j’ai portsentry mais ça ne vient pas de là, j’ai identifié le problème, c’est le filtre postfix-auth qui ban l’ip des mails de Yunohost. La seule chose que je ne comprends pas, c’est pourquoi ces erreurs sont apparues depuis la dernière mise à jour et que les logs indiquent “lost connection after CONNECT” quand je reçois les mails du forum.

fais un cat /var/lib/portsentry/portsentry.history et un cat /etc/hosts.deny pour vérification ça ne coûte rien

Fait. L’ip ne s’y trouve pas, juste dans fail2ban. D’ailleurs ça fonctionne après l’unban mais ça revient, je vais devoir mettre l’ip en liste blanche dans F2b. J’ai la solution mais pas l’explication et ça je n’aime pas trop, j’aime bien comprendre ce qui se passe, du moins avec les explications qu’on peut m’apporter, mes maigres connaissances n’étant pas suffisantes.

Pas sur d’avoir tous les éléments de réponse, mais j’imagine que le

 lost connection after CONNECT

est du au fait que pour diagnostiquer le serveur mail, le serveur de diagnostique se connecte comme un sauvage juste pour avoir ton HELO et se déconnecte comme un malpoli …

1 Like

C’est bien ça, j’ai lancé le diagnostique et j’ai bien les logs “lost connection after CONNECT”

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