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 !
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.
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 !
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).
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.
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
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) > /opt/net.txt
Mais aucun fichier net.ext n’apparaît dans /opt/
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
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 !