INFO - Bug Debian 11 & Webmin/Virtualmin

[PIERREU2]

Bonjour à toutes et à tous,

==== CECI N'EST PAS UNE DEMANDE D'AIDE, MAIS UNE INFORMATION/SOLUTION FACE A DES BUGS ====

Si vous installez Debian 11 et comme package "panel" d'administration Webmin ou/et Virtualmin vous devriez rencontrer des problèmes au niveau des configurations Network.

Il y a en effet visiblement 2 bugs: 1 coté Debian 11 + 1 coté Webmin/Virtualmin

---------- LA PROBLEMATIQUE

Debian, en particulier à partir de la version 11 a fait évoluer son architecture et organisation de fichiers de configuration/paramétrage. Avec notamment des noms de fichiers, certaines syntaxes, des répertoires nouveaux, qui changent (c'est assez subtil et insidieux).

Webmin/Virtualmin qui vous permet (entre beaucoup d'autres choses) de configurer votre Réseau/Network et donc de relier vos IP (et les webserver virtuels) aux interfaces de votre serveur (ethX, enoX,...), n'a pas pris en compte certaines de ces évolutions subtiles de Debian 11.

---------- LE RESULTAT

Votre configuration Network Interfaces/IP ne fonctionne pas, dysfonctionne, oubien créée une instabilité qui nécessite un reboot ponctuel ou périodique du serveur au mieux , voir une réinstallation complète OS, etc...

---------- LA SOLUTION TROUVEE

1/ Vérifier l'état de votre configuration Network par la commande
-> systemctl status networking.service
Probablement vous constaterez un "failure" avec exit status

2/ Vous pouvez avoir de l'info par la commande
-> journalctl -xe

3/ il faut intervenir au niveau de certains fichiers par lignes de commandes

Par rapport au bug semble-t-il du coté Debian 11 ltel qu'installé par OVH, votre serveur dédié est configuré avec son IP primaire en mode DHCP.

Bug debian; Jan 24 16:40:58 nsxxxxxxxx ifup[983]: Waiting for DAD... Done

Perte ping

Dans /etc/network/interfaces.d/50-cloud-init
--> faites une copie du fichier
--> modifier le mode DHCP de l'IP à mode fixe par exemple pour obtenir quelque chose comme ceci:

auto eno3
iface eno3 inet static
address xxx.xxx.xxx.xxx (votre IP4)
gateway xxx.xxx.xxx.254
broadcast xxx.xxx.xxx.255
netmask 255.255.255.0
accept_ra 0

Dans /etc/network/interfaces

--> décommentez la ligne "source-directory /etc/network/interface.d"
--> modifier la ligne en remplacant "source-directory..." par "source /etc/network/interface.d"

--> enregistrez le fichier
--> reboot

En espérant que cela puisse aider utilement.

[JeanR]

Bonjour,

Dans tous les cas, ovh utilise le dhcp pour configurer ses serveurs physiques.
Il est recommandé pour des ip fixes de faire une configuration dans un fichier du serveur.

Il ne sert à rien d'être dépendant d'un système externe tel que le dhcp pour faire fonctionner son serveur, en cas d'incident du service dhcp par exemple, tu perdrais la main sur ta machine alors que le réseau peut fonctionner correctement.

ip fixe --> conf en dur sur le serveur

Bon courage
Captainadmin

[PIERREU2]

Oui en effet.

Utiliser le dhcp est sans aucun doute avantageux pour OVH car cela lui offre plus de souplesse, elle qui doit gérer des variations colossales de serveurs et d'Ip suivant les commandes et fin de services de milliers, millions de clients.

Vu de notre coté client OVH, sauf pour de grands comptes ou dans certaines circonstances pour par exemple "masquer" des IP et réseaux internes importants de serveurs, l'IP fixe est bien préférable.

[janus57]

Bonjour,

Pour information c'est pas un bug debian/virtualmin ce genre de choses arrivent quand le DHCP de OVH a des problèmes car d'autres personnes ont remontée les même soucis sur des OS différents.

Autre infos, pour retirer proprement la config réseau de cloud-init il faut :

To disable cloud-init's network configuration capabilities, write a file /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
network: {config: disabled}

Cordialement, janus57

[PIERREU2]

Bonjour Janus,

Oui pour le DHCP OVH bien entendu Debian et Virtualmin ne sont pas en cause.

Merci pour l'information complémentaire et l'option visant l'inactivation du fichier 50-cloud-init.

C'est une possibilité et dans ce cas, outre l'inactivation de 50-cloud-init, il faudra reporter (correctement) dans le fichier /etc/network/interfaces les parties présentes dans 50-cloud-init.
Attention: faire des sauvegardes et bien configurer faute de planter votre serveur avec tous vos sites !

Personnellement, je privilégie toujours le plus possible de rester/laisser les choses en conformité avec le "produit" de chaque fournisseur et d'intervenir le moins possible dans les fichiers correspondants.
C'est une meilleure garantie de stabilité, d'évolution et pour éviter des problèmes et bien du travail car bien entendu, comme c'est le cas ici entre Debain 11 et Webmin/Virtualmin, le problème est lié au fait que les produits des uns et des autres n'évoluent pas en même temps et peuvent prendre parfois de nouveaux chemins et voire devenir incompatibles.
D'ailleurs Debian a fait le choix (intelligent je trouve) de passer par un système d'inclusion de fichiers paramètres/config séparées.

Bien à vous,
Pierre

[TTY]

Ma proc Debian 11 pour le réseau (IP modifiées) :

Récupérer les infos
ip route
->

default via 94.23.6.254 dev eno1 onlink 
94.23.6.0/24 dev eno1 proto kernel scope link src 94.23.6.55

suppression cloud-init :

apt remove cloud-init
rm -f /etc/network/interfaces.d/50-cloud-init

Conf IP "primaire" :
nano /etc/network/interfaces.d/50-debian
->

auto lo
iface lo inet loopback

auto eno1
allow-hotplug eno1
iface eno1 inet static
address 94.23.6.55
netmask 255.255.255.0
gateway 94.23.6.254
dns-nameserver 1.1.1.1
dns-nameserver 8.8.8.8

Ajout des alias IP failover :
nano /etc/network/interfaces.d/99-failover
->

auto eno1:1
iface eno1:1 inet static
address 87.98.189.55
netmask 255.255.255.255
broadcast 87.98.189.55

auto eno1:2
iface eno1:2 inet static
address 178.32.156.55
netmask 255.255.255.255
broadcast 178.32.156.55

reboot

[Fritz2cat]

/etc/network/interfaces.d/50-cloud-init

Bonjour @TTY

Que fais-tu de tout le bazar IPv6 (près de 300 lignes) donc voici un tout petit extrait du 50-cloud-init ?

iface enp3s0 inet6 static
address 2001:41d0:a:316f::1/56
dns-nameservers 2001:41d0:3:163::1
gateway 2001:41d0:a:31ff:ff:ff:ff:ff
...
pre-down route del -A inet6 2001:41d0:a:3162::/64 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
post-up route add -A inet6 2001:41d0:a:31fe::/64 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
pre-down route del -A inet6 2001:41d0:a:31fe::/64 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
post-up route add -A inet6 2001:41d0:a:3162:8000::/65 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
pre-down route del -A inet6 2001:41d0:a:3162:8000::/65 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
post-up route add -A inet6 2001:41d0:a:31ff:8000::/65 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
 ....

[TTY]

Hello @Fritz2cat,

Je désactive IPV6 (aucun intérêt pour moi tant que l'on ne peut pas les déplacer comme les V4) :

echo "net.ipv6.conf.all.disable_ipv6 = 1" > /etc/sysctl.d/70-disable-ipv6.conf
sysctl -p -f /etc/sysctl.d/70-disable-ipv6.conf

[PIERREU2]

Bonjour @Fritz2cat et @TTY,

Comme quoi il n'existe pas qu'une seule solution ;-)
A chacun celle qui lui convient le mieux dans son contexte.

Mais le plus important est dans le principe qui au fond ici dans chaque solution reste le même, que l'on désactive le /etc/network/interfaces.d/50-cloud-init, ou comme @TTY qu-on remplace le fichier, ou que l'on mette tout dans le fichier /etc/network/interfaces, il faut mettre les bonnes lignes et syntaxes dont on a besoin, dans son propre contexte et fonction de son approche.
Tu ne vas pas gérer 1 à 10 IP qui ne bougent jamais ou peu comme tu vas gérer 100, 1000+ IP qui bougent très régulièrement toutes ou les unes et les autres...

Pour les IPv6, il est vrai qu'elles sont plus compliquées à gérer, et que beaucoup pour ne pas dire le plus grand nombre ne les reconnaît même pas ou ne les utilise pas encore.
Mais là aussi, les grands groupes, les réseaux très conséquents et ceux qui ont besoin de nombreuses IP sont plus concernés et intéressés.
Enfin, inévitablement les IPv6 vont devenir prédominantes avec le temps, alors c'est pas mal non plus de se familiariser avec elles.
Dernier petit avantage, les bloc Ripe IPv4 additionnelles sont désormais facturées par OVH alors que les IPv6/64 sont elles incluses dans l'offre serveur OVH (pour le moment).

Pierre

[TTY]

Enfin, inévitablement les IPv6 vont devenir prédominantes avec le temps, alors c'est pas mal non plus de se familiariser avec elles.

C'est sûrement vrai...
Le problème c'est que ça fait bien 20 ans que j'entends ça.
En attendant, l'IPV6 complexifie la config des outils comme iptables, fail2ban, Portsentry, Crowdsec ... Ce qui augmente :
- la charge marchine pour le filtrage
- la surface d'attaque
- les coûts

Pour un truc qui ne me sert pas (pas de FO), je n'en voie pas l’intérêt.
Comme tu le dis, tout est question de contexte :)