[Résolu] Serveur dédié : Migration vers Debian 9 plus de réseau

Maveric · Octobre 9, 2017, 9:21am

Bonjour à tous,

Me voici depuis 2 jours complètement bloqué.

Environnement :

Serveur Dédier OVH
Debian 9
Kernel 3.14-grsec

Suite à la migration de Debian 8 à 9 j’ai décidé de rebooter afin de remettre un peu tout cela à plat (490j uptime ça ne fait pas de mal du moins en théorie).
Malheureusement pour moi le système boot correctement (confirmé sur l’écran par le technicien ovh), mais ne répond quand même pas au ping, mais dés qu’il est boot autre sur le rescue cela fonctionne.

Évidement tous les tests matériels sont ok, aucune modification logiciel ou matériel ont été faits exception de la MAJ (qui n’est je vous l’accorde pas anodine non plus).

J’ai donc planché sur l’aspect réseaux et j’ai pu constater que sur de multiples sites on parle d’un changement de nom de la carte réseaux sur Stretch change en “ensX”, mais d’après Debian pas si l’on effectue une MAJ .

Mettre à niveau vers Stretch conservera les anciens noms - malgré ce que vous lirez sur le web - supprimer /etc/udev/rules.d/70-local-persistent-net.rules ne vous donnera pas de nouveaux noms même suivi d’un update-initramfs -u et update-grub. (personne n’a pour l’instant trouvé la bonne incantation Debian pour cela ?)

(Source).

Bon beaucoup d’avis divergent sur plusieurs sites je vous pas les détails. Car cela serait, si j’ai bien compris une nouvelle fonctionnalité sur les noyaux v4, hors je l’ai verrouillé en 3.14-grsec pour le moment.

J’ai donc passé les logs au peigne large (oui, car fin serait un peu disproportionné au vu des mes connaissances) dans lequel j’ai pu constater ceci:

Oct  1 11:02:34 srv kernel: e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
Oct  1 11:02:34 srv kernel: e100: Copyright(c) 1999-2006 Intel Corporation
Oct  1 11:02:34 srv kernel: e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
Oct  1 11:02:34 srv kernel: e1000: Copyright (c) 1999-2006 Intel Corporation.
Oct  1 11:02:34 srv kernel: e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
Oct  1 11:02:34 srv kernel: e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0: irq 42 for MSI/MSI-X
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0: irq 43 for MSI/MSI-X
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0: irq 44 for MSI/MSI-X
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: registered PHC clock
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: Intel(R) PRO/1000 Network Connection
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
Oct  1 11:02:34 srv kernel: igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.5-k
Oct  1 11:02:34 srv kernel: igb: Copyright (c) 2007-2013 Intel Corporation.
Oct  1 11:02:34 srv kernel: igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k
Oct  1 11:02:34 srv kernel: igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
Oct  1 11:02:34 srv kernel: Intel(R) 10 Gigabit PCI Express Network Driver - version 4.1.2
Oct  1 11:02:34 srv kernel: Copyright (c) 1999-2015 Intel Corporation.
Oct  1 11:02:34 srv kernel: i40e: Intel(R) Ethernet Connection XL710 Network Driver - version 1.0.11-k
Oct  1 11:02:34 srv kernel: i40e: Copyright (c) 2013 - 2014 Intel Corporation.
Oct  1 11:02:34 srv kernel: ixgb: Intel(R) PRO/10GbE Network Driver - version 1.0.135-k2-NAPI
Oct  1 11:02:34 srv kernel: ixgb: Copyright (c) 1999-2008 Intel Corporation.

est donc plus particulièrement cette parti la :

Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: registered PHC clock
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: Intel(R) PRO/1000 Network Connection
Oct  1 11:02:34 srv kernel: e1000e 0000:01:00.0 eth0: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF

Pour moi donc normalement pas de changement.

J’ai tout de même testé plein de choses trouvées pour connaitre le nouveau nom de l’interface au cas ou il aura tout de même changé comme « networkctl » ou « ls /sys/class/net/ »
Bien tenté héhé, mais non sa marche pas vu que je suis sur un live (dans le cul lulu)

Je dois avouer que je sèche un peu. Bien évidement étant donné que c’est une Kimsufi le support m’aide pour mon argent

voici mon fichier /etc/network/interfaces (inchangée depuis 7 ans)

# 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 **.**.83.24
        netmask 255.255.255.0
        network **.**.83.0
        broadcast **.**.83.255
        gateway **.**.83.254

Voila si quelqu’un aurait une idée. J’ai actuellement relancé quelques services depuis le mode rescue en ayant monté mes partitions, mais c’est du très provisoire.

Merci d’avance pour votre aide

PascalHambourg · Octobre 1, 2017, 11:50am

Un tel uptime est déraisonnable pour un serveur public, à moins de patcher le noyau à chaud avec ksplice/kpatch. Il y a forcément eu des failles de sécurité découvertes et des mises à jour du noyau publiées pour les corriger dans tout ce temps.

Et en vrai français ?

Les précédentes versions d’udev créaient une règle de nommage persistant pour chaque interface dans le fichier /etc/udev/rules.d/70-local-persistent-net.rules. La version de d’udev de Stretch ne le fait plus, mais continue à appliquer les règles existantes si ce fichier existe. Sinon, le nouveau nommage “persistant” n’est pas toujours de la forme “ensX”, cela dépend de la plate-forme matérielle. Un nommage fréquent est de la forme “enpXsY[fZ]” ou X et le numéro de bus PCI et Y le numéro de “slot” et Z le numéro de fonction du contrôleur ethernet tels qu’on peut les voir dans la sortie de lspci (sans les 0 devant).

Tu peux donc tenter d’ajouter un paragraphe avec ce nom supposé dans /etc/network/interfaces.

Non, rien à voir avec le noyau donc inutile de rester sur un noyau obsolète. C’est une fonctionnalité de systemd appelée “Predictable netswork interface names”.

La partie des messages que tu cites est lors de la création de l’interface par le pilote e1000e. Le renommage a lieu plus tard. Il y a généralement un autre message du noyau qui l’indique, avec l’ancien nom et le nouveau nom de l’interface.

Tu peux insérer dans le démarrage un script qui va enregistrer la sortie de la commande ip link contenant le nom de l’interface.
Le paramètre net.ifnames=0 passé à la ligne de commande du noyau permet de désactiver le nouveau nommage prévisible.

Maveric · Octobre 1, 2017, 4:57pm

Bonjour Pascal,

Merci beaucoup pour ce retour rapide et aussi précis.

Tu as raison mais n’étant pas suffisant au point sur la manipulation de kernel, j’ai pour le moment utilisé les versions patchers GRSEC fournis par OVH.

C’est un mode live que propose OVH dans la liste des netboots. Il permets de booté sur un Live Recue et donne un accès distant dessus.
Avec un mount on peut donc accéder aux partitions de notre système.

/etc/udev/rules.d/70-persistent-cd.rules/

# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.

Donc vide.
Je suppose que malgré l’existence de ce fichier il génère un nouveau nom.

Dans les logs Syslogsou Kernel aucune indication de changement de nom de réseau.
Kernel logs suite

Je viens d’effectuer plusieurs tests mais je n’ai toujours pas réussi.

Voici ce que j’ai tenté :
modification du fichier dans /etc/default/grub
GRUB_CMDLINE_LINUX="net.ifnames=0"
Mais je ne peut faire un ‘update-grub’ sans que cela me fasse des erreurs
Update-grub logs

J’ai donc tenté ensuite de l’intégré directement dans /etc/grub.d/06_OVHkernel
06_OVHkernel

Puis tenté d’intégrer un petit script au démarrage dans /etc/rc2.d/S08Reseaux
Scripts réseaux

Sans résultat, puis essayé dans /etc/init.d/reseaux (777)

Et enfin tenté de le mettre dans /etc/crantab
2 * * * * root /etc/init.d/reseaux

Toujours rien.

Je commence être en grosse difficulté car je ne comprend pas pourquoi si mon système fonctionne au reboot rien de ce que j’ai programmé ne ce lance.

Concernant la déduction du nom de la carte réseaux je dois avouer séché un peu aussi.

lspci
00:00.0 Host bridge: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 09)
00:1c.0 PCI bridge: Intel Corporation NM10/ICH7 Family PCI Express Port 1 (rev 02)
00:1d.0 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB controller: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation NM10/ICH7 Family SMBus Controller (rev 02)
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

Merci de ton aide Pascal

PascalHambourg · Octobre 1, 2017, 6:04pm

Je doute que les patchs grsec d’il y a plus d’un an protègent contre toutes les failles de sécurité découvertes et corrigées depuis. OVH ne met pas à disposition des noyaux plus récents ?

Je sais ce qu’est le mode rescue d’OVH. Mais ta phrase n’était pas du français correct et ne voulait rien dire.

Ce n’est pas le bon fichier : persistent-net-rules.

Ce log ne m’a pas l’air complet. Il manque le début, et peut-être la fin.

Tu as oublié de monter /proc, et peut-être /dev et /sys.

Inutile, le contenu des scripts de /etc/grub.d/ n’est pris en compte que lors de l’exécution d’update-grub. Le plus simple était de modifier directement /boot/grub/grub.cfg.

Maintenant je crains que l’exécution ratée de update-grub ait laissé un fichier grub.cfg vide.

Avec le nommage basé sur la position dans le bus PCI, le nom devrait être enp1s0.

Maveric · Octobre 1, 2017, 10:22pm

Voici le shell que j’ai tenté dans lequel j’ai tenté de le régénérer
https://pastebin.com/k2dMXNtp

Ce fichier est vide
/etc/udev/rules.d/75-persistent-net-generator.rules
# just an empty file

Bon je pense que tu a raison j’ai malheureusement endommager je pense le grub
/boot/grub/grub.cfg

Pourtant au premier coup d’œil il ne me parait pas incohérent.

Lorsque que le serveur reboot sur sont Disque dur il ne génère plus aucun logs. J’en conclu donc qu’il ne peut plus boot.

2em tentative avec un Tuto suivi :

root@rescue:~# mount /dev/sda1 /mnt/
root@rescue:~# mount -o bind /dev/ /mnt/dev
root@rescue:~# mount -o bind /sys/ /mnt/sys
root@rescue:~# mount -t proc proc /mnt/proc
root@rescue:~# chroot /mnt
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@rescue:/# mount -a
mount: sysfs is already mounted or /sys busy
root@rescue:/# os-prober
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

root@rescue:/# update-grub2
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Generating grub configuration file ...
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Found linux image: /boot/bzImage-3.14.51-xxxx-grs-ipv6-32
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
done

OUFFF sauvé le système reboot a nouveau merci beaucoup.

Le souci réseau lui persiste mais j’ai pu obtenir ceci de mon script de boot

Demarrage du log : 01-10-2017 23H41

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
    link/ether c2:6c:e6:2a:df:87 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
    link/ether 2a:18:fc:f3:d5:f7 brd ff:ff:ff:ff:ff:ff
4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 26:0e:4f:37:e2:a0 brd ff:ff:ff:ff:ff:ff
5: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
    link/ether 7a:a3:29:9d:d9:ae brd ff:ff:ff:ff:ff:ff
6: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:22:4d:83:30:c0 brd ff:ff:ff:ff:ff:ff
7: teql0: <NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 100
    link/void
8: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
    link/ipip 0.0.0.0 brd 0.0.0.0
9: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
    link/sit 0.0.0.0 brd 0.0.0.0
10: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default
    link/tunnel6 :: brd ::

j’ai donc tenté a nouveau mon fichier interface sur le eth0.
Sans résultat.

J’ai donc fini par un dernier reboot dans lequel je viens de compiler dans un fichier compressez tout les logs apres avoir tout archivé pour n’avoir que les 2 dernier boot et de manière propre.

Logs.rar

Je vais au lit je suis épuisé.

Merci beaucoup de ton aide Pascal en tout cas j’ai beaucoup appris aujourd’hui grâce a toi.

J’espère rétablir rapidement le service pour mes users qui s’impatiente.

Cordialement

PascalHambourg · Octobre 1, 2017, 10:28pm

Ton script de boot, il est exécuté à quel moment, pour savoir si c’est avant ou après la configuration du réseau ?

En attendant de comprendre tu peux ajouter des commandes pour activer et configurer l’interface pour au moins pouvoir te connecter au serveur en mode normal.

/bin/ip link set dev eth0 up
/bin/ip addr add **.**.83.24/24 dev eth0
/bin/ip route add default via **.**.83.254

Maveric · Octobre 2, 2017, 4:09pm

Bonjour Pascal,

Mon script est dans /etc/init.d (Mon debian a toujours sont boot system en SysV Init).
Nom : reseaux (777)

#!/bin/bash

### BEGIN INIT INFO
# Provides:          reseaux
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: monter reseaux et log
# Description:       up le link eth0 + logs les cartes
### END INIT INFO

logs=/root/log-reseaux
jour=$(date "+%d-%m-%Y %HH%M")

echo "" >> $logs
echo "" >> $logs
echo "------------------------------------------------------------" >> $logs
echo "Demarrage du log : "$jour >> $logs
echo "------------------------------------------------------------" >> $logs

ifconfig >> $logs

echo "" >> $logs

ip link >> $logs

echo "" >> $logs

uname -a >> $logs

/bin/ip link set dev eth0 up
/bin/ip addr add **.**.83.24/24 dev eth0
/bin/ip route add default via **.**.83.254

echo "------------------------------------------------------------" >> $logs
echo "fin du log : " >> $logs
echo "------------------------------------------------------------" >> $log

J’ai tenté ensuite de l’activer par

root@rescue:~# update-rc.d reseaux default
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US:en",
        LC_ALL = "en_US.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
usage: update-rc.d [-n] [-f] <basename> remove
       update-rc.d [-n] [-f] <basename> defaults
       update-rc.d [-n] <basename> disable|enable [S|2|3|4|5]
                -n: not really
                -f: force

Mais finalement j’ai lancer webmin puis activé sur du runlevel 2.

Ai-je raté quelque chose ?
Le runlevel 2 ne suffit t’il pas dois-je envisager de le mettre encore plus tard ?

J’ai tenter aussi de mettre une tache planifier qui se relance toute les minute pour l’exécuter au cas où.

Mais au vu des logs le serveur ne doit plus démarrer car il n’en contient plus aucun de nouveau. Mais OVH eux disent dans leur rapport.

Le serveur est démarre (demande du 'login' a l'ecran) mais inaccessible par le réseau (pas de 'ping').
Un redémarrage sur un noyau standard OVH ('netboot') ne corrige pas la situation.

Actions entreprises: 
Redémarrage du serveur sur mode 'rescue' (Linux)

Resultat: 
Boot OK. Systeme 'rescue' accessible.

Maveric · Octobre 2, 2017, 4:23pm

Je commence a manquer de temps. Malheureusement je crains que je vais devoir finir par ré-installer.

J’aurai poussé ce serveur du Debian 6 au Debian 9.

Je garde quand même encore un peu espoir de trouvé une solution. En tous cas OVh à transmis une demande de support à Kimsufi mais jamais eu un retour de leur part.

PascalHambourg · Octobre 2, 2017, 9:17pm

Et c’est maintenant que tu le dis, après tout le temps perdu avec les histoires de nommage qui ne concernent que systemd ?

C’est “defaults” avec un “s”.

Le script networking est exécuté au runlevel S, donc plus tôt que ton script.

Maveric · Octobre 3, 2017, 6:43pm

Bon voilà après un acharnement est un manque clairement de soutien de OVH et même de malhonnête de leur part j’ai cracker.

J’ai fini par tout dump sur mon PC et relancé l’installation sur une base propre.

Je tiens particulièrement à te remercier PascalHambourg car grâce à toi j’ai beaucoup appris, j’ai surtout découvert que malgré les connaissances que je penser avoir je suis à la ramasse.

En partit dû à la mauvaise habitude de m’aider de Webmin pour gagner du temps, quand j’avais, faut le dire, la fainéantise de cherche plus loin que le bout de mon nez.

Cette difficulté ma emmener à réfléchir sur ma façon d’utiliser Debian. Bien sûr ne l’utilisant que de manière assez limité je ne vais pas tout savoir sur tout mais me posé de bonne question et pas forcément cherche la réponse dans des solutions simple comme webmin.

J’ai déjà commencé a bien éplucher le system rcX.d d’ailleurs d’autre questions arriverons sur de nouveau poste sur le forum je pense.

Encore une fois Merci Pascal de la réactivité et la précision de tes réponse quand je me suis retrouver dans la galère. J’espère un jour pouvoir te renvoyer l’appareil.

Bonne soirée encore beaucoup de boulot a tout remettre en service.

Cordialement