Reconfigurer connexion réseau upifdown

Support Debian
Tags: #<Tag:0x00007f63f34d19e0>
#1

Bonjour,

J’ai un serveur (OVH) que j’administre avec mes maigres connaissances dans ce domaine.
À tel point que j’ai fait une erreur récemment : supprimer le paquet ifupdown
Au redémarrage, évidement, plus d’accès SSH

Désormais, je suis en rescue et j’essaye de diagnostiquer le problème.
Bien sûr, j’ai tenté de remonter le système (mount /dev/sda1 /mnt puis chroot /mnt) afin de réinstaller upifdown, sans résultat.

Avez-vous des conseils ou un petit guide pour vérifier que la configuration réseau est correctement faites ?

Un service networking restart me donne :

    [warn] Running /etc/init.d/networking restart is deprecated because it may not re-enable some interfaces ... (warning).
    [....] Reconfiguring network interfaces...RTNETLINK answers: File exists
    ifup: failed to bring up eth0
    failed.

Voilà, je suis prêt à donner plus de détail. Quel logs pourrait me donne plus d’indice sur ma situation ?

Je vous serais très reconnaissant,

Belle année !

#2

Pourrais-tu nous indiquer la version de Debian installer sur le serveur ?

Pour effectuer un chroot de ton système il te faudra bien plus que monter la partition sda1, afin de pouvoir fonctionner le système aura besoin aussi que tu monte les bind systèmes etc

mount  /dev/sda1 /mnt

mount --bind /dev /mnt/dev
mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys

chroot /mnt /bin/bash

En supposant que ta partition racine soit bien sda1

En générale la première partition est la partition /boot sur les système installer par un provider, la seconde étant la swap et le restant la racine du système.

Je dirais donc plus un truc comme ça :

mount /dev/sda3 /mnt/
mount /dev/sda1 /mnt/boot
mount --bind /dev /mnt/dev
mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys
chroot /mnt /bin/bash

Tu monte donc ta racine sur mnt ainsi que la partition /boot dans son répertoire et les bind requis, puis tu déclare le shell en lançant ton chroot du système.

#3

Bonjour et merci pour ces bons conseils !

Alors, la version de Debian est Stretch 9.6

Pour monter correctement les partitions, voici ce que renvoie un lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk
├─sda2   8:2    0 445.7G  0 part
├─sda3   8:3    0   511M  0 part
└─sda1   8:1    0  19.5G  0 part

Pour être plus complet, fdisk -l donne :

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         4096  40962047  40957952  19.5G 83 Linux
/dev/sda2        40962048 975718399 934756352 445.7G 83 Linux
/dev/sda3       975718400 976764927   1046528   511M 82 Linux swap / Solaris

Si j’ai bien compris me concernant :

  • sda1 est le boot et le système
  • sda2 est le dossier /home/ de mon système
  • sda3 est le swap

Voici la manœuvre que j’ai effectué :

mount /dev/sda1 /mnt
mount /dev/sda2 /mnt/home

mount --bind /dev /mnt/dev
mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys

chroot /mnt /bin/bash

apt-get update
apt-get install ifupdown

Malheureusement, après un reboot normal, le serveur n’est toujours pas accessible en SSH.
D’après la précédente intervention d’un technicien, le serveur démarre (demande du ‘login’ à l’écran) mais inaccessible par le réseau (pas de ‘ping’). Un redémarrage sur un noyau standard OVH (‘netboot’) ne corrige pas la situation.

J’aimerais savoir si je peux trouver un log qui me renseignerait davantage.

Merci à toi Clochette pour tes conseils !

#4

Tu peux ajouter une tâche planifiée (dans le crontab) qui viendra écrire ta configuration réseau dans un fichier, comme, par exemple, la commande suivante :
(ip a;ip r;cat /etc/resolv.conf) > /opt/net.txt
Et, là, tu sauras dans quel état est vraiment ton réseau (parce qu’il est possible que ton serveur SSH ne réponde plus pour une autre raison).
En attendant, si on peut avoir le contenu du fichier /etc/network/interfaces du système installé (pas celui du rescue).

#5

Je vais mettre en place la tâche CRON pour en savoir plus, merci de l’astuce, je vous communiquerai le contenu du log.

Voici contenu du fichier /etc/network/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.59.36.196
        netmask 255.255.255.0
        network 37.59.36.0
        broadcast 37.59.36.255
        gateway 37.59.36.254

iface eth0 inet6 static
        address 2001:41d0:0008:4bc4::1
        netmask 128
        dns-nameservers 2001:41d0:3:163::1
        post-up sleep 5; /sbin/ip -family inet6 route add 2001:41d0:0008:4bff:ff:ff:ff:ff dev eth0
        post-up sleep 5; /sbin/ip -family inet6 route add default via 2001:41d0:0008:4bff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del default via 2001:41d0:0008:4bff:ff:ff:ff:ff
        pre-down /sbin/ip -family inet6 route del 2001:41d0:0008:4bff:ff:ff:ff:ff dev eth0

On m’a indiqué que la configuration se fait désormais dans le fichier
/etc/systemd/network/50-default.network

J’ai donc créé ce fichier qui n’existait pas et remplit comme suit :

# This file sets the IP configuration of the primary (public) network device.
# You can also see this as "OSI Layer 3" config.
# It was created by the OVH installer, please be careful with modifications.
# Documentation: man systemd.network or https://www.freedesktop.org/software/systemd/man/systemd.network.html

[Match]
MACAddress=00:22:4d:7a:4d:d2

[Network]
Description=network interface on public network, with default route
DHCP=no
Address=37.59.36.196/24
Gateway=37.59.36.254
#IPv6AcceptRA=false
NTP=ntp.ovh.net
DNS=127.0.0.1
DNS=213.186.33.99
DNS=2001:41d0:3:163::1
Gateway=2001:41d0:0008:4bff:ff:ff:ff:ff

[Address]
Address=fe80::222:4dff:fe7a:4dd2/64

[Route]
Destination=2001:41d0:0008:4bff:ff:ff:ff:ff
Scope=link

Ce qui ne fonctionne pas mieux.

#6

Est-ce que tu as essayé de te connecter au serveur dédié par le biais de son “IPMI” ?

https://docs.ovh.com/fr/dedicated/utilisation-ipmi-serveurs-dedies/

Tous les serveurs dédiés proposés actuellement par OVH en disposent. Cela te permettra au moins de configurer manuellement le réseau pour remettre en route le serveur. Et il n’y aura pas à s’encombrer d’un chroot pour tenter de comprendre le soucis.

–
AnonymousCoward

#7

On en découvre des choses avec vous !

J’aurais apprécié passé par l’IPMI (je ne connaissais pas), malheureusement cette possibilité n’est pas présente pour un serveur Kimsufi (en tout cas, l’option n’apparaît pas dans l’interface de gestion Kimsufi).

Pour revenir à Cron, je n’arrive pas à créer la tâche …

crontab -e

Puis j’ajoute la ligne suivante :

*/5 * * * * (ip a;ip r;cat /etc/resolv.conf) &gt; /opt/net.txt

Mais aucun fichier net.ext n’apparaît dans /opt/

#8

En éditant directement le fichier /etc/crontab à l’intérieur du chroot, en ajoutant à la ligne que cela est à exécuter sous l’utilisateur root, ça doit fonctionner correctement.

Chez moi, ça marche.

–
AnonymousCoward

#9

Finalement, toutes mes excuses, le problème venait d’ailleurs.

Grâce à vos conseils, j’ai remarqué que les services ne démarrait tout simplement pas au démarrage.
J’ai donc compris que le problème venait d’un changement de kernel effectué juste après mon passage à Stretch (. J’avais oublié de redémarrer donc j’ai poursuivi mes configurations, et quelques jours plus tard en désinstallant ifupdown, patatra. Je suis donc revenu à un ancien kernel 3.16.0-4-amd64 à la place du 4.9.0-3-amd64 qui à l’air de poser soucis chez moi.

Je suis désolé de vous avoir importuné avec des questions qui n’était pas lié à mon vrai problème : mon incompétence.
Vous m’avez permis de maîtriser enfin crontab (après avoir retourné la documentation).
Le montage des partitions, le chroot, IPMI, autant de notions que je vous dois !

Le sujet est résolu, merci beaucoup !

1 J'aime