[Jessie] [kimsufi] Login sans réseau au boot

Support Debian
#1

Sur un serveur kimsufi en Debian 8 qui fonctionne depuis plusieurs mois sans soucis, et pour lequel je n’ai pas fais de changement (conf, update, etc.) récemment. Il n’est pas accessible sur le réseau (ne répond pas au ping), mais affiche le prompt.
OVH me l’à passé en mode rescue, j’ai utilisé leurs tests (CPU, mémoire, réseau), sans soucis.
En mode rescue le réseau fonctionne: je m’y connecte en SSH et j’accède à d’autres adresse depuis la machine.

J’ai ouvert un ticket chez OVH, mais vu qu’ils sont pas rapides, je cherche des idées pour continuer l’investigation en mode rescue…

Ci dessous le retour d’incident OVH et un ping.

Rapport intervention OVH:

Cette opération a été achevée le 2017-04-27 10:33:15
Voici les détails de cette opération:

Boot sur interface diagnostique (rescue)
Date 2017-04-27 10:20:30, teddy D a fait Boot sur interface diagnostique (rescue):
Voici le detail de l'intervention realisee:

Le serveur est demarre (demande du 'login' a l'ecran) mais inaccessible
par le reseau (pas de 'ping').
Un redemarrage sur un noyau standard OVH ('netboot') ne corrige pas la
situation.

message: "please enter the username to you authentify on the server"
Actions entreprises: Redemarrage du serveur sur mode 'rescue' (Linux)
Resultat: Boot OK. Systeme 'rescue' accessible.
Recommandations: Configuration logicielle a corriger par le client

Ping :

root@rescue:~# ping wikipedia.fr
PING wikipedia.fr (78.109.84.114) 56(84) bytes of data.
64 bytes from  (78.109.84.114): icmp_seq=1 ttl=58 time=8.34 ms
64 bytes from wikimedia2.typhon.net:icmp_seq=2 ttl=58 time=8.29 ms
64 bytes from wikimedia2.typhon.net:icmp_seq=3 ttl=58 time=8.23 ms
64 bytes from wikimedia2.typhon.net:icmp_seq=4 ttl=58 time=8.24 ms
64 bytes from wikimedia2.typhon.net:icmp_seq=5 ttl=58 time=8.25 ms
64 bytes from wikimedia2.typhon.net:icmp_seq=6 ttl=58 time=8.30 ms
^C
--- wikipedia.fr ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 8.234/8.280/8.346/0.064 ms
#2

Bonjour,

Ne serait-ce pas tout bêtement la configuration de l’interface réseau qui n’est pas bonne ?

#3

Alors peut être… Mais j’avoue que la config manuelle du réseau pour moi se limite à /etc/network/interfaces, et en plus je n’ai jamais utilisé IPV6.

En l’occurrence, en remontant mon root et en y jetant un oeil, je ne vois rien d’anormal. La config et les adresses ont été ajoutées à l’install, j’imagine qu’elles sont fiable:

root@rescue:/mnt/etc/network#  cat interfaces
    # This file describes the network interfaces available on your system
    # and how to activate them. For more information, see interfaces(5).

# The loopback network interface
    auto lo
    iface lo inet loopback

    auto eth0
    iface eth0 inet static
    	address 37.x.y.127
    	netmask 255.255.255.0
    	network 37.x.y.0
    	broadcast 37.x.y.255
    	gateway 37.x.y.254

iface eth0 inet6 static
	address 2001:-:-:-::1
	netmask 128
	dns-nameservers 2001:-:-:-::1
	post-up /sbin/ip -family inet6 route add 2001:-:-:-:ff:ff:ff:ff dev eth0
	post-up /sbin/ip -family inet6 route add default via 2001:-:-:-:ff:ff:ff:ff
	pre-down /sbin/ip -family inet6 route del default via 2001:-:-:-:ff:ff:ff:ff
	pre-down /sbin/ip -family inet6 route del 2001:-:-:-:ff:ff:ff:ff dev eth0

En revanche, je ne sais pas où est la config réseau du mode rescue d’OVH, il n’y a rien dans /etc/network/interfaces - interfaces.d:

root@rescue:/# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

root@rescue:/# ls /etc/network/interfaces.d/
root@rescue:/#

Quand à ma dernière MàJ me semble hors de cause, elle a plus d’un mois:

root@rescue:/mnt/var/log/apt# zcat history.log.1.gz
Start-Date: 2017-03-16  09:54:04
Commandline: apt-get upgrade
Upgrade: bind9-host:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), liblwres90:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), apache2-utils:amd64 (2.4.10-10+deb8u7, 2.4.10-10+deb8u8), libdns100:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), libisc-export95:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), linux-image-3.16.0-4-amd64:amd64 (3.16.39-1, 3.16.39-1+deb8u2), libisccfg90:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), apache2-mpm-prefork:amd64 (2.4.10-10+deb8u7, 2.4.10-10+deb8u8), libbind9-90:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), vim-common:amd64 (7.4.488-7+deb8u1, 7.4.488-7+deb8u2), bind9:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), dnsutils:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), vim-tiny:amd64 (7.4.488-7+deb8u1, 7.4.488-7+deb8u2), apache2-data:amd64 (2.4.10-10+deb8u7, 2.4.10-10+deb8u8), vim:amd64 (7.4.488-7+deb8u1, 7.4.488-7+deb8u2), passwd:amd64 (4.2-3+deb8u1, 4.2-3+deb8u3), bind9utils:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), libmagickwand-6.q16-2:amd64 (6.8.9.9-5+deb8u6, 6.8.9.9-5+deb8u8), login:amd64 (4.2-3+deb8u1, 4.2-3+deb8u3), apache2:amd64 (2.4.10-10+deb8u7, 2.4.10-10+deb8u8), apache2-bin:amd64 (2.4.10-10+deb8u7, 2.4.10-10+deb8u8), imagemagick-common:amd64 (6.8.9.9-5+deb8u6, 6.8.9.9-5+deb8u8), libisccfg-export90:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), libdns-export100:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), libmagickcore-6.q16-2:amd64 (6.8.9.9-5+deb8u6, 6.8.9.9-5+deb8u8), libirs-export91:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), libisccc90:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10), vim-runtime:amd64 (7.4.488-7+deb8u1, 7.4.488-7+deb8u2), libisc95:amd64 (9.9.5.dfsg-9+deb8u9, 9.9.5.dfsg-9+deb8u10)
End-Date: 2017-03-16  09:55:52

J’avance pas des masses… si t’as des pistes, ça m’intéresse!