Plantage serveur Kimsufi, plus accès à rien

Support Debian
#1

Bonjour à tous,

J’ai un serveur kimsufi sous Debian 8.10 (Jessie) (oldstable) (64bits) que je souhaitais upgrader puisque certains paquets de mises à jour dans webmin échouaient.
J’ai rencontré des erreurs dès le départ, suivi ce tuto https://phoenixnap.com/kb/how-to-upgrade-debian-8-jessie-to-debian-9-stretch.
J’ai eu des soucis avec libre office common et d’autres a supprimés (apparemment) puis avec ma sources list . J’ai quelques screen si besoin.

Bref en tentant de passer à buster hier, tout à planté, plus d’accés a winscp, rutorrent, ni rien. il me semble avoir vu dans putty une erreur avec MySQL aussi.
Je ne sais pas quoi faire, ça dépasse mes maigres compétences pour le coup.
A part tout réinstaller mais franchement ça m’embête, d’une parce que c’est un serveur multicomptes bien spécial qui a été monté par une personne, donc je serai incapable de tout refaire. De deux ce serait perdre tout le contenu, ça fait ch*** (disque de 2To plein à environ 70%)

Si un pro, une âme charitable dans le coin se sent capable de checker le problème, je lui passe volontiers la main.
C’est ça ou la résiliation et après 4 ans ben c’est triste.

Un grand merci d’avance
Briga

#2

Je ne connais pas trop OVH (si si) mais tu as une option sous la main pour rebooter le serveur en mode recovery, sur la même machine mais avec une distrib live. Tu as peut être aussi un accés genre KVM qui te permet de voir le boot de ta machine comme si tu étais devant.
En tous cas en recovery, tu peux monter les disques, regarder dans les logs ce qui coince, réinstaller grub, faire des install comme si tu étais sur ta machine normal (en chroot).
Mais je n’ai pas le temps de te dépanner là maintenant. Et je suis trés cher. :smiley:

#3

Oui donc c’est pas pour moi. Je n’ai pas monté le serveur à l’époque mais une personne qui s’y connait bien. Mes compétences s’arrêtent aux mises à jour et pannes simples, de quoi entretenir le serveur quoi. je suis plutôt branché hardware que software, chacun son truc.
Mais merci quand même :wink:

#4

Bonjour,

Upgrader de jessie à stretch puis ensuite à buster avec des erreurs au premier upgrade, c’est suicidaire ?

Même en mode recovery, ça risque de pas être la joie…

Bon courage.

#5

Il n’y a pas eu d’upgrade sous strech. il y a eu des conflits avec plusieurs paquets, mais j’avais encore accès à tout. c’est pendant l’up à buster que ça a coincé.
Même en voulant mettre le rtmv2 à jour ça coincait déjà.

#6

Il n’y a pas eu d’upgrade sous strech.

J’ai un serveur kimsufi sous Debian 8.10 (Jessie) (oldstable) (64bits) que je souhaitais upgrader puisque certains paquets de mises à jour dans webmin échouaient.
J’ai rencontré des erreurs dès le départ, suivi ce tuto https://phoenixnap.com/kb/how-to-upgrade-debian-8-jessie-to-debian-9-stretch.
J’ai eu des soucis avec libre office common et d’autres a supprimés (apparemment) puis avec ma sources list . J’ai quelques screen si besoin.

Bref en tentant de passer à buster hier, tout à planté, plus d’accés a winscp, rutorrent, ni rien. il me semble avoir vu dans putty une erreur avec MySQL aussi.

Là je ne suis pas…

#7

Je me suis inspiré du tuto mais pour buster

#8

On peut se poser la question : pourquoi diantre avoir des paquets libreoffice* sur un serveur ?
Sur un poste client

fp2@debpacha:~$ aptitude  why  libreoffice
i   task-xfce-desktop Recommande libreoffice
fp2@debpacha:~$

Autant je comprend la présence de paquets texlive* ou latex* installés comme dépendance de r-base* (GNU R) ou de pandoc, autant je ne vois pas comment des paquets libreoffice pourraient être présents sur un serveur, vu l’aspect interaction avec l’utilisateur de ce genre de logiciel.

Non le système n’a pas planté, il a tout simplement perdu l’accès au réseau. Avant de faire la migration de stretch vers buster, vous n’avez pas prêté l’attention nécessaire au problème des noms d’interfaces de réseau persistantes.
Par exemple, sur un HP microserver, j’étais arrivé ç la conclusion que les interfaces seraient renommées

   eth1 -> enp3s0f1
   eth0 -> enp3s0f0

et en fait elles ont été renommées eno1 et eno2.
Si c’est bien un problème réseau, la seule solution envisageable est la réparation via le mode rescue selon la page indiquée par mattotop mais comme je vois le prérequis suivant

    Avoir un accès en SSH (root) à votre serveur dédié

je ne sais que penser. (Pour ma part, j’ai dû me déplacer pour régler le problème ).
La page du mode rescue (OVH) n’est pas d’une clarté limpide, car après avoir parlé de prérequis, on a le paragraphe

 Utiliser le SSH (lignes de commande)

où vous avez l’IP du serveur.

Peut-être faut-il comprendre prérequis savoir utiliser la ligne de commandes via SSH ?

Bon courage,
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

#9

Le serveur n’a pas été monté par moi-même. Il est assez spécifique, c’est un multicompte (j’ai décrit ce que je souhaitais, la personne en a fait l’arborescence)
Rutorrent, plex, pydio, webmin etc.
Un admin (moi) 2 utilisateurs rutorrent, pour les autres (famille, amis) ils n’ont accès qu’au sftp en mode restreint ou plex.
Si tel ou tel paquets qui doivent ou pas être présents ce n’est pas à moi de le dire.

Quand je dis planté c’est une façon de parler, plus d’accès = plantage, panne ce que voulez…
j’ai bien compris qu’il fallait l’accès ssh (j’ai les bases quand même) mais c’est là que ça coince… Connection refused
Ou alors je m’y prend mal ahaha en même temps suis pompier pas dev ça se saurait :wink:

#10

Mode rescue kimsufi:

1: Créer une paire de clefs ssh
2: Se connecter au manager kimsufi
3: En haut à gauche (onglet: votre nom), choisir SSH
4: Y coller votre clef publique:

5:Retour au tableau de bord, onglet netboot, choisir “Rescue: rescue64pro”:

6:Redémarrer
7: Se connecter en SSH en utilisant la clef privée générée précédemment (ip du serveur sur port 22).
8:Dans la console saisir “fdisk -l” pour identifier le disque du serveur (/dev/sdxx)
9:Monter ce disque sur mnt “mount /dev/sdxx /mnt”
10: saisir “chroot /mnt”
11: à partir de là tu peux regarder tes logs et ton sources.list etc…, corriger, relancer un update, un upgrade,…
12: Une fois fait, retour au manager kimsufi à l’onglet netboot et choisir disque dur et redémarrer.

#11

Je suis arrivé à l’étape 11 sans problème, mais j’avoue qu’après j’hésite à aller plus loin, suis presque devenu parano et pas trop l’envie de faire une connerie :sweat_smile:

#12

Bonjour,

Quelqu’un a une idée de la marche à suivre ? J’ai édité le fichier sources.list pour corriger les erreurs, enfin tenter de corriger et je rencontre ça. A chaque étape c’est une galère

#13

Quelles erreurs ? Pourrait-on avoir le contenu du fichier ?

Ce qui est galère, c’est de deviner ce que vous faites et si la fenêtre texte dont vous donnez une image peu lisible a été prise dans un environnement netboot avant ou après un chroot éventuel.

Le message de nestor en 12 points me semble un très bon point de départ. On pourrait ajouter
0 Se munir de papier, crayon et prévoir une large plage horaire au calme.
7 a Charger la clé avec la commande ssh-add (si ce n’est pas déjà fait )
7 b se connecter en SSH depuis un terminal avec un tampon d’historique largement dimensionné
7 c dans le shell obtenu, déterminer si les commandes suivantes sont disponibles

which script
which tmux

9 b Après le montage de la racine sur /mnt vous pouvez chercher comment ont été nommées les interfaces réseau

less /mnt/var/log/messages

et vous cherchez renamed from eth
et vous comparer avec ce qui se trouve dans /mnt/etc/network/interfaces ( à éditer si besoin est )
10 a Avant de procéder au chroot il y a un certain nombre de systèmes de fichiers à monter en mode bind

for d in $(basename -a /dev /proc /sys )
do  
 mkdir /mnt/$d
 mount --bind /$d /mnt/$d
done

Cette liste est peu-être incomplète :disappointed_relieved:

Avant le chroot les fichiers de configuration sont dans /mnt/etc par exemple /mnt/etc/apt/sources.list

  1. Je suppose que la fenêtre que vous avez collée a lieu après le chroot lors d’un apt update ou apt upgrade.
    Je suis au regret de vous annoncer que le paquet phpmyadmin n’est pas disponible dans buster et donc de la même manière que Cahuzac était une source inépuisable d’ennuis pour le Parti Socialiste, il vaudrait mieux mettre phpmyadmin de côté.

Je pense qu’il faut d’abord vérifier si c’est un problème de noms d’interfaces réseau et régler ce problème avant de s’attaquer au reste de la mise à jour. Autrement dit, d’abord s’assurer une connexion SSH sur le Kimsufi pour administrer tranquillement sans passer par le mode rescue.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#14

J’entends bien tout ce que vous me dites, sauf que là on a largement dépasser mon stade de compétences. Donc je crois que le mieux pour moi, au lieu d’accumuler erreurs sur erreurs, et de ne pas comprendre la moitié de ce que je fais c’est d’arrêter les frais.
En tout cas merci beaucoup :wink: