Erreur openssh-server après upgrade

Je suis en déplacement donc la situation n’est pas facile à gérer mais c’est rassurant de voir des gens aussi compétents qui peuvent m’aider.

J’ai essayé de commenter dans /etc/network/interfaces l’interface eth0:0 avec cette étrange adresse IP asiatique mais ça n’a rien changé, serveur toujours non pingable en mode normal.

Plus tard j’aimerai bien comprendre le pourquoi de cette interface mais il faut maintenant tenter de changer le nom de l’interface.

Voici donc ma sortie:

root@195-154-216-106:~# basename -a $(echo /sys/class/net/*)
eno1
enp2s0
lo
root@195-154-216-106:~#
root@195-154-216-106:~# udevadm info /sys/class/net/eth0 | fgrep -i PATH
Unknown device "/sys/class/net/eth0": No such device
root@195-154-216-106:~#
root@195-154-216-106:~# udevadm test-builtin net_id /sys/class/net/eth0 2 > /dev/null
root@195-154-216-106:~#

Le fgrep me donne ça:

root@195-154-216-106:~# fgrep -r eth0 /etc
/etc/dhcp/dhclient.conf:#  interface "eth0";
/etc/dhcp/dhclient.conf:#  interface "eth0";
/etc/network/interfaces:#auto eth0
/etc/network/interfaces:#iface eth0 inet static
/etc/network/interfaces:auto eth0  
/etc/network/interfaces:iface eth0 inet static  
/etc/network/interfaces:#auto eth0:0
/etc/network/interfaces:#iface eth0:0 inet static
/etc/network/interfaces~:#auto eth0
/etc/network/interfaces~:#iface eth0 inet static
/etc/network/interfaces~:auto eth0  
/etc/network/interfaces~:iface eth0 inet static  
/etc/network/interfaces~:auto eth0:0
/etc/network/interfaces~:iface eth0:0 inet static
/etc/udev/rules.d/70-persistent-net.rules:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:1e:a1:3b:21:f6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
/etc/initramfs-tools/initramfs.conf:# Specify a specific network interface, like eth0

J’imagine qu’il faut donc que je remplace toutes les occurences de eth0 par enp2s0.

Mais je n’ai pas compris ce que je devais déplacer dans mon home, le fichier
/etc/udev/rules.d/70-persistent-net.rules
afin qu’il soit ignoré ? Même s’il est corrigé avec enp2s0 ?

Mais donc si je fais tout ça (avec “update-initramfs -u -k all” pour finir) n’y aurait il pas un risque de ne plus pouvoir accéder au serveur en mode rescue qui actuellement semble se convenir de l’ancien nommage d’interface ?

Sinon sur les serveurs d’Online on peut visiblement utiliser iLO, cela pourrait peut-être aider…

Quoiqu’il en soit cette histoire de changement de nommage d’interface réseau fait très mal, ça plus mon souci initial de sshd on peut dire que ma migration est un cas d’école d’upgrade catastrophique (et c’est pas fini je sens).

Merci, Vincent.

Pas besoin d’être root. Je suppose que la console de secours donne un accès root avec un certain nombre de services non démarrés. Toujours est-il que nous avons des interfaces dont les noms sont à la mode. (pas ethX ).
Nous avons donc deux interfaces, pour connaître leur état ( up ou down ) et la configuration IP associée

for i in  eno1 enp2s0
do
   ip address show dev $i
done

et vous trouverez laquelle a pour adresse IPv4 195.154.216.106
Vous pouvez aussi vous rassurer en passant la commande udevadm info /sys/class/net/<interface>

Vous avez la chance d’avoir dans l’arborescence /etc seulement un fichier qui fait référence à eth0 (en supposant que c’est la bonne racine / qui est utilisée ). En éditant /etc/network/interfaces n’oubliez pas de supprimer la partie eth0:0à moins que l’adresse à Singapour (qui se termine par .36 ) soit celle de l’interface iLO (à demander à Online).

comment voulez-vous le corriger puisqu’il ne contient pas la chaîne eth0 et qu’il n’existe peut-être pas ? Vérifiez son existence et son contenu. C’est à mon avis une source d’ennui potentiel.

Il se pourrait bien, que comme monsieur Jourdain vous utilisiez cette interface iLO sans le savoir dans le mode de secours. Et avec un peu de chance le nom de l’interface serait eno1 Consultez le maître de philosophie des réseaux pour savoir ce qu’il en est exactement.

systemctl   status -l networking.service 

En résumé

  • contacter Online
  • vérifier UUID du système de fichiers racine.
  • Modifier /etc/network/interfaces
  • Mettre à jour initramfs
  • Mettre un cierge à Saint Antoine et redémarrer

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


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

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

1 J'aime

Si si le fichier /etc/udev/rules.d/70-persistent-net.rules contient bien 2 lignes avec eth0 et eth1):

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
 
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:1e:a1:3b:21:f7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
 
# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="44:1e:a1:3b:21:f6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Si je le “corrige” pas besoin de le déplacer ?

Étrange, tu as bien des règles udev qui forcent le nom des interfaces en eth0 et eth1, comme je le supposais.
J’ai bien l’impression que les noms en01 et enp2s0 sont ceux employés par le système de secours (ce qui serait logique si tu travailles dans un environnement chrooté avec /sys monté en lien).

AMHA, le problème vient d’ailleurs…
Il faudrait examiner le syslog quand tuas démarré le serveur en mode « normal »

Faudra m’expliquer pourquoi la commande fgrep ne l’a pas trouvé. La seule explication plausible est que les systèmes de fichiers racine sont différents entre mode de secours et mode normal.
On tourne en rond, cela peut durer longtemps.
Essayez de noter toutes les infos permettant d’y voir plus clair
sorties de

df -hTx tmpfs
lsblk --fs
ip address show

Puis vous faites un tableau avec deux colonnes mode de secours et mode normal et des lignes avec UUID des périphériques bloc, nom et adresse MAC des interfaces réseau, …
Comparez aussi avec les adresses MAC qui se trouvent dans /etc/udev/rules.d/70-persistent-net.rules
DE toute façon vous aurez besoin de ces informations pour votre courriel à Online.

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)

@littlejohn75
Par correction.

La commande fgrep a trouvé 70-persistent-net.rules

Si ce fichier était bien dan la sortie de fgrep postée plus haut !

Nous sommes d’accord @Vinz : nos réponses se sont croisées.

Il n’en reste pas moins qu’il te faut suivre les directives.
Et une feuille et un crayon t’aideront bien.

Ne confonds pas le mode urgence de ton serveur et le mode chroot sur ton vrai serveur.
Ce dernier équivaut à peu de chose près à un mode normal.

Les prises de notes sont à faire pour ces deux modes.

Continue tes démarches et pose encore des questions si besoin.
N’hésite-pas.

Nous reviendrons sur ce /etc/udev/rules.d/70-persistent-net.rules
Ce n’est peut-être pas le même en mode urgence et en mode chroot.

Courage !

PS : Dans le post de @anon70622873 disant comment procéder au chroot et faute de mieux,
je recommande simplement de préciser le Shell voulu :

sudo chroot /mnt /bin/bash

En mode rescue sans chroot:

turman@195-154-216-106:~$ df -hTx tmpfs
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  1,9G     0  1,9G   0% /dev
/dev/loop0     squashfs  485M  485M     0 100% /lib/live/mount/rootfs/img.current.squashfs
overlay        overlay   2,0G  193M  1,8G  10% /
/dev/sda2      ext4      916G  705G  165G  82% /mnt
turman@195-154-216-106:~$ lsblk --fs
NAME   FSTYPE   LABEL UUID                                 MOUNTPOINT
loop0  squashfs                                            /lib/live/mount/rootfs/img.current.squashfs
sda                                                        
├─sda1 ext4     /boot 54e0bfeb-4c89-4f26-a0eb-e0afde40706c 
├─sda2 ext4     /     a8ac874e-2e31-4ae7-9ca2-4d62bd54ed75 /mnt
└─sda3 swap           b989aa61-cf22-4287-98e9-e7a1bef031ef [SWAP]
turman@195-154-216-106:~$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 44:1e:a1:3b:21:f6 brd ff:ff:ff:ff:ff:ff
    inet 195.154.216.106/24 brd 195.154.216.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::461e:a1ff:fe3b:21f6/64 scope link 
       valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 44:1e:a1:3b:21:f7 brd ff:ff:ff:ff:ff:ff

En mode rescue apres chroot:

turman@195-154-216-106:~$ sudo chroot /mnt /bin/bash
root@195-154-216-106:/$df -hTx tmpfs
Sys. de fichiers Type     Taille Utilisé Dispo Uti% Monté sur
/dev/sda2        ext4       916G    705G  165G  82% /
udev             devtmpfs   1,9G       0  1,9G   0% /dev
root@195-154-216-106:/$lsblk --fs
NAME   FSTYPE   LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
loop0  squashfs                                                           
sda                                                                       
├─sda1 ext4     /boot 54e0bfeb-4c89-4f26-a0eb-e0afde40706c                
├─sda2 ext4     /     a8ac874e-2e31-4ae7-9ca2-4d62bd54ed75  164,1G    77% /
└─sda3 swap           b989aa61-cf22-4287-98e9-e7a1bef031ef                [SWAP]
root@195-154-216-106:/$ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 44:1e:a1:3b:21:f6 brd ff:ff:ff:ff:ff:ff
    inet 195.154.216.106/24 brd 195.154.216.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::461e:a1ff:fe3b:21f6/64 scope link 
       valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 44:1e:a1:3b:21:f7 brd ff:ff:ff:ff:ff:ff

Les adresses MAC sont donc les mêmes et Online m’a confirmé que c’était bien enp2s0 sans trop savoir ce qu’était eno1.

Je vais donc renommer eth0 en enp2s0 juste dans /etc/network/interfaces. Le forçage de nom dans 70-persistent-net.rules ne semblant pas fonctionner et à priori ça sert à rien de le renommer puisque le nom original devrait déjà être enp2s0 si je comprend bien.

Résultat dans quelques instants :slight_smile:

Je viens de relire la release note il vaut mieux commenter ou renommer le fichier, je vais donc le faire, c’est d’ailleurs ce qu’avait préconisé littlejohn75, c’est plus clair maintenant :slight_smile:

Comment corriges-tu eth0:0 ?

Avec enp2s0:0 ?

A bien été fait depuis le mode chroot ?

J’ai pas corrigé eth0:0, j’ai luste laissé commenté. Et oui update-initramfs a été executé une fois chrooté.

Mais ça n’a pas marché, et plus embêtant le serveur est maintenant non pingable même en mode rescue, ce qui est assez gênant il faut bien l’avouer…

et en mode normal ?

Tu as voulu aller un peu vite ; désolé pour toi.
Ils prennent des € chez online pour réinstaller une buster ou une stretch sur ton dédié ?
Je n’ai pas vraiment d’idée de comment ça marche.

J’espère que tu as des sauvegardes.

Le ping répond @Vinz !

ping 195.154.216.106
PING 195.154.216.106 (195.154.216.106) 56(84) bytes of data.
64 bytes from 195.154.216.106: icmp_seq=1 ttl=54 time=15.8 ms
64 bytes from 195.154.216.106: icmp_seq=2 ttl=54 time=16.1 ms
64 bytes from 195.154.216.106: icmp_seq=3 ttl=54 time=15.10 ms
64 bytes from 195.154.216.106: icmp_seq=4 ttl=54 time=16.3 ms
^C
--- 195.154.216.106 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 15.824/16.041/16.277/0.230 ms

Et le service SSH aussi :

rem@n73sm ~ $ ssh 195.154.216.106
The authenticity of host '195.154.216.106 (195.154.216.106)' can't be established.
ECDSA key fingerprint is SHA256:1EMcB40tOfAQVI1DrqA1w9pdigNrjlK3FpB/23W0JRg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '195.154.216.106' (ECDSA) to the list of known hosts.
rem@195.154.216.106's password: 
Permission denied, please try again.
rem@195.154.216.106's password: 
Permission denied, please try again.
rem@195.154.216.106's password: 
rem@195.154.216.106: Permission denied (publickey,password).
rem@n73sm ~ $ 

En fait j’étais pas encore revenu en mode rescue, mais je peux encore m’y logguer, ouf !

Mais sinon oui le renommage de eth0 n’a rien changé au mode normal, il doit y avoir (encore) autre chose comme le présentait Bruno…

Il faut que je tente iLO !

Edit: décidément nos posts se croisent @anon44391915 !

Je te conseillerais bien de désactiver le service apache2 temporairement (en chroot)
Puis voir si ce mode normal revient OK après un redémarrage.

sudo systemctl stop apache2
sudo systemctl disable apache2

Qu’entends-tu par là ?
J’ai du mal à me faire une idée.

Je voulais juste dire que ça n’a rien changé, en mode normal le serveur est toujours non pingable.

Et comment diable le serveur Apache pourrait être responsable de la non pingabilité du serveur ? Cela me semble juste impossible…

Le service peut planter, je ne sais pas : c’est une piste facile à essayer.
Je crois que la nuit porte conseil :slight_smile:

Alors j’ai essayé iLO avec 3 manières différentes mais sans succès:

  • console en Java (Linux et Windows)
  • console en OneClick (Windows)
  • via l’appli iLO mobile (Android) mais mon phone ne supporterai pas des connexions TLS fortes (!!)

Quand ça ne veut pas ça ne veut pas…

Sinon je réfléchis à une solution peu glorieuses qui serait de me louer un nouveau serveur. En fait ça fait longtemps que j’y songé car ma Dedibox date de 2012. Seulement lorsque j’avais comparé les offres il y a 2 ans j’avais préféré gardé ma vieille Dedibox à 35€ HT par mois car en plus d’avoir 4 GB de RAM et 1 To de disque elle a surtout des cores rapides même s’il n’y en a que 2. Lorsque j’avais testé les offre récentes il y avait certes plein de coeur (8 de mémoire) donc une puissance globale correcte mais des scores mauvais en mono-thread. Mais là je vois qu’il y a pour le même prix un serveur à base de Xeon (E3 1220 v2) 6 cores avec 16 GB de RAM et 2x1 To, ça pourrait m’intéresser.

Mais ça serait quand même bien de comprendre le problème sur mon serveur actuel…