«Temporary failure in name resolution» pendant la postinstall

Mon serveur YunoHost

Matériel: PC fixe
Version de YunoHost: 3.5.2
J’ai accès à mon serveur : En direct avec un clavier/écran
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

Bonsoir,

La postinstallation se déroulait sans accroc, jusqu’à ce qu’il me dise qu’il ne parvient pas à récupérer un fichier. En fait, il semble ne plus pouvoir se connecter nulle-part à cause d’un «temporary failure in name resolution». Je tentais d’installer une appli hotspot après que celle du vpn se soit déroulée sans accroc.

Si tu as accès en ligne de commande à ton serveur, éssaie de tester si la résolution dns fonctionne:

ping wikipedia.org

Si ça ne fonctionne pas, ça vient peut être de ton VPN qui fournit des DNS actuellement en panne ?

Ça me donne le même message d’erreur. Et je peux pinger le VPN qui fournit le DNS sans problème depuis une autre machine.

Ben le problème vient de ton .cube ou de ton fournisseur de VPN, les DNS configurés dans le .cube sont en panne.

Tu peux en configurer d’autres en allant sur l’interface qui permet de configurer le VPN.
Sur cette page il y a des adresses pour un résolver DNS ouvert: https://arn-fai.net/recursif

Ça a marché. Pour une raison que j’ignore, il y avait juste localhost dans le fichier resolv.conf

Le problème, c’est que le fichier vient d’être remis dans son état d’avant sans raison (j’ai juste interrompu un processus d’installation d’une app). Comment empêcher ça ?

Est-ce que tu veux dire localhost, ou bien 127.0.0.1 ?

D’avant … mais avant quoi du coup ?

Laquelle du coup … parce que c’est probablement lié à l’app en question … le fichier /etc/resolv.conf ne change pas juste comme ça sans raison

Normalement il y a un service qui s’apelle resolvconf dont le seul job est normalement de s’assurer que le fichier /etc/resolv.conf pointe vers 127.0.0.1. Mais lorsqu’on installe d’autres services suceptibles de magouiller la conf réseau (au hasard, NetworkManager) alors c’est la guerre et ils se bataillent pour le controle de ce fichier … Donc idéalement (dans le contexte de YunoHost) il ne faut pas installer NetworkManager.

  1. Oui, c’est bien 127.0.0.1, ce qui revient au même.
  2. L’état où il contenait seulement 127.0.0.1, avant que je ne corrige manuellement.
  3. J’ai voulu installer nextcloud, mais j’ai interrompu le processus quand il m’a demandé dans quel domaine je voulais l’installer. Ça m’a paru bizarre que ça aie pour conséquence de bousiller à nouveau le fichier de conf.
  4. Je ne pense pas avoir installé network manager. Et je ne comprends toujours pas le lien de cause à effet entre le redémarrage du VPN et la magouille de ma conf réseau (ça arrivait dans 100% de mes tentatives).

J’ai trouvé une solution qui a fonctionné pour moi: https://stackoverflow.com/questions/53687051/ping-google-com-temporary-failure-in-name-resolution

Est-ce que c’est pas “simplement” que le service dnsmasq était tombé en panne ?

Pour nextcloud si tu as arrété avant la fin des questions, c’est quasi sûr que c’est pas ça.

Non, c’est pas ça. D’ailleurs, le problème est réapparu, comme ça, sans raison apparente. Les ip des DNS que j’ai entrés manuellement dans resolv.conf sont toujours là et le vpn répond quand je le ping depuis une autre machine.