Serveur inaccessible

Guillaume · 25 févr. 2021, 15:25

Bonjour,

Je dispose d'un serveur (VPS OVH) installé sous Debian 10... jusqu'à ce 23 février, il fonctionnait très bien.
Je l'utilise pour :
* Node-Red
* InfluxDB
* Grafana

Il est maintenant inaccessible que ce soit en SSH ou via les ports correspondants aux applications installées.

Je me suis connecté avec le KVM OVH et je remarque plein de logs concernant apparmor.

Il n'y a rien dans les logs concernant mes différentes tentatives de démarrage.
J'ai reçu une réponse du support OVH me signifiant que tout les ports étaient fermés... je n'ai jamais demandé ça.

Je jette donc une bouteille à la mer en espérant qu'une âme charitable se penche sur mon cas.

Si des infos supplémentaires sont nécessaires, je peux les fournir.

Merci d'avance

25 févr. 2021, 17:55

Salut,

Le support d'OVH est le plus minable qui existe. Calamiteux...
Ne compte pas sur eux.

Je ne récupère généralement pas mes machines avec KVM (D'ailleurs les logs que tu donne n'aide pas.) mais avec un netboot,
Ensuite ssh, montage de tes partitions et chroot si nécessaire.

Tu faisais quoi sur la machine au moment de perdre la main ?
Tu as des choses sensibles sur ce serveur ?

Bon courage.

Guillaume · 25 févr. 2021, 18:07

Merci de ta réponse!

Effectivement le support est minable...

Je ne faisais rien de spécial, je n'étais même pas connecté à ce moment là. Je l'ai remarqué aujourd'hui.

Des données sensibles, non! Mais j'aimerais ne pas devoir tout réinstaller.

Le KVM en mode RESCUE, ce n'est pas comme un netboot?

SSH, Montage de partition, je connais mais chroot moins, comment ça s'utilise?

dezix · 25 févr. 2021, 18:34

Salut,

Ce que tu nommes KVM en mode Rescue
c'est le "Rescue Mode" (session live accessible depuis le Tableau de bord (interface web) du compte client OVH ?
... ou c'est autre-chose ?

Guillaume · 25 févr. 2021, 18:35

C'est bien la session live

dezix · 25 févr. 2021, 19:33

Dans la session Rescue d'OVH vérifie bien la lettre du disque du VPS,
ça doit être /dev/sdb (c'est un risque d'erreur)

Vérifie aussi ce qui est monté ; je crois me souvenir que ça monte certaines parts du VPS
=> il faut (peut-être) les démonter pour pouvoir les remonter dans le chroot

Si tu nécessites le chroot

voici la marche à suivre (avec montage de /boot pour réinstaller GRUB p.ex)
=> remplacer les sdxy par ce qu'il faut (c'est juste une marche générale à adapter)

Code : Tout sélectionner

Rescue		# mkdir /mnt/chroot

Rescue		# mount /dev/sdxy /mnt/chroot		(partition racine du VPS)
Rescue		# mount --bind /dev /mnt/chroot/dev
Rescue		# mount --bind /run /mnt/chroot/run		(optionnel)
Rescue		# mount -t proc /proc /mnt/chroot/proc
Rescue		# mount -t sysfs /sys /mnt/chroot/sys

Rescue		# chroot /mnt/chroot				(début du chroot)

	chroot		# mount /dev/sdxz  /boot  		(BIOS/UEFI)		si nécessaire
	chroot		# mount /dev/sdxz  /boot/efi		(UEFI)			si nécessaire
	
	chroot		# <cmdes passées sur le système installé>
	......
	chroot		# umount /boot/efi		   (UEFI)
	chroot		# umount /boot			(BIOS/UEFI)
	chroot		# exit			
	(fin du chroot)
	
Rescue		 retour à la session Rescue

Rescue		# umount /mnt/chroot/dev
Rescue		# umount /mnt/chroot/proc
Rescue		# umount /mnt/chroot/sys
Rescue		# umount /mnt/chroot

Terminé !

Voilà si ça peut te débrouiller, c'est juste un pense-bête que j'utilse (sans garantie)

25 févr. 2021, 19:50

Salut,

dezix a écrit : 25 févr. 2021, 18:34c'est le "Rescue Mode" (session live accessible depuis le Tableau de bord (interface web) du compte client OVH ?

Je vais faire mon poilu mal embouché.
C'est de la merde...
Le seul truc valable c'est le rescue64Pro (Tu démarre sur une ISO qui te permet de diagnostiquer/réparer)

Tu changes le boot ici:

Capture.PNG

Tu choisi le rescue64pro (Bien pompeux pour une Iso de Debian 8... Les mecs chez OVH se prennent un peu pour des cadors - les pauvres, s'ils savaient...)
(N'oublie pas de mettre ton mail pour recevoir tes accès.

Capture2.PNG

Ensuite redémarre ta machine. Dans ton manager, même page que les captures.

Tu pourras te connecter en SSH et faire des diagnostics, vérifier tes partitions, réparer (si c'est possible).
Mais... Il faut s'y connaitre un minimum. Le chroot est presque le minimum.
https://www.turnkeylinux.org/docs/chroo ... air-system

Vu ce que tu dis (Pas de manipulation ou de connexion au moment de la perte de contrôle) je pencherais pour 2 choses:
- Crash matériel
- Piratage. Mais c'est rare à moins que tu ne soit VRAIMENT pas prudent (genre clef sur le contact)...

Voilà, désolé d'être aussi cynique, mais je suis chez OVH depuis bientôt 15 ans, je connais la musique.
J'en ai pour 1000€ mensuel de machines chez eux.

N'espère pas les lumières du support, c'est mort...

Edit: pas si sur que le boot rescue64 soit possible sur un vps...

Guillaume · 25 févr. 2021, 21:55

Je teste tout ça demain... j'ai un peu regarder, j'arrive à chrooter mon système mais après je suis perdu pour savoir où regarder.

J'ai beau fouillé le site d'Ovh je ne vois pas d'autres solutions que le mode Rescue.

Visiblement, il y a bien eu un problème matériel sur mon VPS mais il est réglé selon OVH.

26 févr. 2021, 05:14

Salut,

Guillaume a écrit : 25 févr. 2021, 21:55Je teste tout ça demain... j'ai un peu regarder, j'arrive à chrooter mon système mais après je suis perdu pour savoir où regarder.

J'ai beau fouillé le site d'Ovh je ne vois pas d'autres solutions que le mode Rescue.

Visiblement, il y a bien eu un problème matériel sur mon VPS mais il est réglé selon OVH.

Oui les VM ne se démarrent pas avec le mode rescue64 comme les dédiés.
S'il y a eu un problème matériel ce n'est pas réglé ? Tu as redémarré sur le système en mode normal pour voir ?

Guillaume · 26 févr. 2021, 07:51

Selon OVH, l'incident est clos...

J'ai redémarré (plusieurs fois même) mais tout ce que j'obtiens c'est la capture d'écran dans mon premier post.
Dans cet état, je ne sais rien faire de mon VPS, il semble "freezé" dans cet état.

dezix · 26 févr. 2021, 10:23

Sans écrire le véritable IP de ton serveur, quelle est la commande que tu utilises pour obtenir la sortie de la capture du postage #1 ?

... je n'y vois rien de bien "causant " (pour moi) à part qu'il y a du apparmor

Je suppose donc AppArmor est activé dans /etc/default/grub.d/apparmor.cfg

As-tu testé de le désactiver c'est peut-être ça qui merde ???

26 févr. 2021, 10:41

Si tu as une sauvegarde, c'est le moment de la ressortir.
Ca te prendra moins de temps que d'essayer de réparer . C'est certes moins formateur, mais plus rapide

Guillaume · 26 févr. 2021, 11:34

@dezix : Avant de faire ça, j'ai pu avancer, je garde cette solution sous le coude.
La capture du post #1, c'est l'affichage du KVM.
@piratebab : Je n'ai pas de sauvegarde...mais ça m'apprendra à en faire ;)

En fouillant, j'ai trouvé comment sortir plus d'infos de ce KVM et maintenant je vois que le démarrage bloque sur

Code : Tout sélectionner

Configuring network interfaces...ifup: waiting for lock on /run/network/ifstate.eth0

Ca parle à quelqu'un?

26 févr. 2021, 11:38

c'est l'activation de l'interface réseau. Est ce que tu as acces à la ligne de commande pour faire quelques tests ?

Guillaume · 26 févr. 2021, 11:40

Je peux démarrer mon serveur en rescue, ça suffira?

Je suis prêt à faire un chroot avec ceci

Code : Tout sélectionner

mount /dev/sdb1 /mnt
mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev
mount -t sysfs none /mnt/sys/

Je dois ajouter quelque chose?

dezix · 26 févr. 2021, 12:38

Si tu as conservé l'install de base => tout sur sdb1, oui ça doit suffire.

Mais ne monte pas sdb1 directement sur /mnt plutôt sur /mnt/sdb1 ou ... ce que tu voudras

Pourquoi mets tu "none" ?
je ne crois pas que cela va le faire

Je ne suis pas certain que -o bind soit exactement équivalent à --bind
mais tu peux tester, à ce stade je ne pense pas que cela puisse représenter un risque (à part de ne pas permettre la même chose).

Ensuite, si tu ne parviens pas à ce que tu veux faire,
tu ressors du CHROOT et tu ajoutes ....

Guillaume · 26 févr. 2021, 12:44

Justement, qu'est ce que je peux faire pour tenter de rétablir ce VPS?

Ca me semble bizarre que /run/network/ soit vide.

dezix · 26 févr. 2021, 12:50

Si tu ne montes (--bind) pas /run c'est vide !
C'est le noyau qui tourne (rescue) qui fournit tout ce que tu montes avant le CHROOT

Guillaume · 26 févr. 2021, 13:42

Une étape en plus... lors du boot, le serveur semble vouloir manipuler eth0.

En faisant un ifconfig sur mon serveur en mode rescue, je remarque qu'il n'y a pas d'interface eth0 mais plutôt ens3.

Ca se modifie quelque part?

Edit:

J'ai récupéré mon serveur en modifiant le fichier /etc/network/interfaces.d/50-cloud-init.

Ce point est ordre!

26 févr. 2021, 14:31

pense à passer en résolu.Tu as du avoir une mise à jour suivie d'un redémarrage qui a changé le nom de l'interface réseau.

Serveur inaccessible Le sujet est résolu