la connexion ssh ne fonctionne pas. Aucun message d’erreur, ça ne répond simplement pas (j’ai laissé “tourner” la commande pendant plus d’une demi-heure)
je remarque également ne plus recevoir d’emails, bien que mes clients n’indiquent aucun message d’erreur
D’autres services/applications, comme Nextcloud ou FreshRSS pour n’en citer que deux, semblent fonctionner sans souci.
J’ai tenté un reboot depuis mon compte Kimsufi, mais je rencontre ce que je pense être un autre problème pour lequel j’ai fait un ticket (`No netbootld found").
J’ai également tenté d’exécuter une commande depuis n8n (echo "MonPassword" | sudo reboot) mais soit je m’y prends mal, soit ce n’est pas possible…
Peut-être qu’il ne reste plus d’espace libre sur ton système de fichier ?
Je suppose qu’il y a un mode « rescue » chez Kimsufi avec lequel tu pourrait booter, monter le système de fichier et faire de la place si mon hypothèse hasardeuse est bonne.
Je peux me tromper, mais il me semblait que l’outil de diagnostic prévenait lorsque l’espace disque arrivait à saturation. Par ailleurs, mes sauvegardes borg font 300Go, le disque fait 1To, donc j’avais exclu cette hypothèse (mais peut-être y a-t-il effectivement une partition système saturée ?)
Côté Kimsufi, l’interface ressemble à ça. Donc à part “Redémarrer”, je ne sais trop que faire (j’avoue ne pas savoir ce à quoi “NetBoot” correspond).
Je pense que c’est bel et bien une fonction de ton hébergeur pour « démarrer en réseau ». Je suppose que derrière le bouton, il y a le choix d’un OS de secours qui aurait la même fonction que booter un PC planté avec une clé USB pour avoir accès à des outils de diagnostic ou pour réinstaller.
Je redémarrerais, maintenant qu’on est sur que c’est pas juste un problème d’espace disque et voir si, par le plus beau des hasard, ça refonctionne correctement ou pas.
Ce que je ne comprends pas c’est ce qui te donne l’impression que Nextcloud et FreshRSS fonctionnent.
Parce que si il n’y a pas de ping et que la machine n’a pas de réseau ou de résolution de nom … je vois pas commet ces deux applications fonctionneraient.
Peut-être voir avec un nmap depuis ton ordi vers ton serveur pour voir ce qu’il y a comme ports ouverts.
Exemple avec ma brique Internet…
sudo nmap -sT tierce.nohost.me
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-01 12:48 CEST
Nmap scan report for tierce.nohost.me (80.67.181.227)
Host is up (0.074s latency).
Other addresses for tierce.nohost.me (not scanned): 2001:913:1fff:ffff::b:d0fe
Not shown: 991 filtered ports
PORT STATE SERVICE
22/tcp closed ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
443/tcp open https
587/tcp open submission
993/tcp open imaps
5222/tcp open xmpp-client
5269/tcp open xmpp-server
Nmap done: 1 IP address (1 host up) scanned in 11.89 seconds
Avant le reboot, je pouvais effectivement utiliser sans problème Nextcloud ou FreshRSS, entre autres…
Maintenant que je ne parviens qu’à démarrer en mode rescue, évidemment toutes ces applis sont down.
Donc jusqu’à présent, ce que j’ai fait c’est :
monter la partition /dev/sda2 sur /mnt
chroot sur /mnt
tentative de mise à jour du système, pour constater que ça échoue :
# apt update
Err:1 http://debian.mirrors.ovh.net/debian bullseye InRelease
Temporary failure resolving 'debian.mirrors.ovh.net'
Err:2 http://security.debian.org/debian-security bullseye-security InRelease
Temporary failure resolving 'security.debian.org'
Err:3 https://download.docker.com/linux/debian bullseye InRelease
Temporary failure resolving 'download.docker.com'
Err:4 https://packages.sury.org/php bullseye InRelease
Temporary failure resolving 'packages.sury.org'
Err:5 https://last-public-ovh-kernel.snap.mirrors.ovh.net/debian ovhkernel InRelease
Temporary failure resolving 'last-public-ovh-kernel.snap.mirrors.ovh.net'
Err:6 http://forge.yunohost.org/debian bullseye InRelease
Temporary failure resolving 'forge.yunohost.org'
Err:7 http://debian.mirrors.ovh.net/debian bullseye-updates InRelease
Temporary failure resolving 'debian.mirrors.ovh.net'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://debian.mirrors.ovh.net/debian/dists/bullseye/InRelease Temporary failure resolving 'debian.mirrors.ovh.net'
W: Failed to fetch http://security.debian.org/debian-security/dists/bullseye-security/InRelease Temporary failure resolving 'security.debian.org'
W: Failed to fetch http://debian.mirrors.ovh.net/debian/dists/bullseye-updates/InRelease Temporary failure resolving 'debian.mirrors.ovh.net'
W: Failed to fetch https://download.docker.com/linux/debian/dists/bullseye/InRelease Temporary failure resolving 'download.docker.com'
W: Failed to fetch https://packages.sury.org/php/dists/bullseye/InRelease Temporary failure resolving 'packages.sury.org'
W: Failed to fetch https://last-public-ovh-kernel.snap.mirrors.ovh.net/debian/dists/ovhkernel/InRelease Temporary failure resolving 'last-public-ovh-kernel.snap.mirrors.ovh.net'
W: Failed to fetch http://forge.yunohost.org/debian/dists/bullseye/InRelease Temporary failure resolving 'forge.yunohost.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
du coup, je tente un ping google.com qui échoue aussi (Temporary failure in name resolution), mais ping 8.8.8.8 réussit.
Depuis mon ordinateur, voici ce que donne nmap :
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-01 12:59 CEST
Nmap scan report for ------
Host is up (0.015s latency).
Other addresses for ----- (not scanned): -------
Not shown: 997 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
25/tcp filtered smtp
79/tcp open finger
Nmap done: 1 IP address (1 host up) scanned in 1.71 seconds
Ah oui, suis-je bête… Mais même avec les bons droits, je ne parviens pas à éditer /etc/resolv.conf, j’obtiens de la part de vim : "resolv.conf" E166: Can't open linked file for writing
Hello, je ne sais pas si c’est en lien mais depuis une mise à jour j’ai un nouvel avertissement dans le diagnostic : La résolution DNS semble fonctionner, mais il semble que vous utilisez un /etc/resolv.conf personnalisé. Le fichier /etc/resolv.conf doit être un lien symbolique vers /etc/resolvconf/run/resolv.conf lui-même pointant vers 127.0.0.1 (dnsmasq). Si vous souhaitez configurer manuellement les résolveurs DNS, veuillez modifier /etc/resolv.dnsmasq.conf.
ça n’a pas apporté de problèmes chez moi, mais je n’ai touché à rien pour que cet avertissement apparaisse. Peut-être qu’une mise à jour a modifié la manière dont ces fichiers sont configurés ? (si ça aide à comprendre l’origine du pb…)
Mais j’aimerais bien comprendre ce qu’il s’est passé…