NetworkManager erreur bizarre, solution actuel pénible...

VINDICATORs
Messages : 53
Inscription : 24 mars 2015, 14:38

NetworkManager erreur bizarre, solution actuel pénible...

Message par VINDICATORs » 26 janvier 2019, 13:01

Bon... Ce problème se rencontre tant sur RHEL, que sur CentOS.

Lors de la configuration des périphériques réseaux en modifiant uniquement les fichiers, il arrive parfois que le système se mélange les pinceaux et crée 2 périphériques eth1 (pour donner un exemple) 1 avec l'UUID d'origine avec les paramètres d'origine (souvent en dhcp), le deuxième avec un nouvel UUID et les nouveaux paramètres.
Cela provoque tout un tas de dysfonctionnement aléatoire car la bonne configuration n'est pas toujours active sur le moment.

Du coup il arrive qu'il prenne soit la bonne configuration, soit celle d'origine.

Cela ressemble beaucoup à ce bogue :
https://bugzilla.redhat.com/show_bug.cgi?id=1654098

Du coup, si j'ai bien suivi, dans mon cas il faut faire le ménage dans ce répertoire :

Code : Tout sélectionner

/var/lib/NetworkManager/
Supprimer les .states qui ne servent pas.
Faire une purge du fichier timestamps

Et relancer la connexion

Code : Tout sélectionner

nmcli connection up eth1
Cela fonctionne (à confirmer en production ce lundi), même avec des personnes qui font des actions derrières.
Il semble que ce soit à cause des Baux de renouvellement de connexion qui sont très important et qui se marchent dessus.

Donc la question est :
Est-ce que quelqu'un connait une meilleur solution pour purger automatiquement ces fichiers au lieu d'avoir parfois deux périphériques qui apparaissent lorsque l'on fait des modifications?
Car cela peut apparaitre aussi si l'on manipule avec nmtui (interface graphique en ligne de commande).

Si vous avez besoin d'une visu sur un cas concret (résultat de commandes et autres) n'hésitez pas.

Beta-Pictoris
Messages : 1017
Inscription : 07 janvier 2014, 21:48
Localisation : Angers, France

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par Beta-Pictoris » 27 janvier 2019, 02:11

Network-Manager peut associer plusieurs profils à une même interface.

Si tu fait une modification importante dans un profil, par exemple changer son type, Network-Manager va créer un nouveau profil et garder l'existant.

Il vaut, donc, mieux arrêter un profil et le supprimer pour ensuite le récréer:

Code : Tout sélectionner

nmcli connection down nom_du_profil
nmcli connection delete nom_du_profil
Dernière modification par Beta-Pictoris le 27 janvier 2019, 14:00, modifié 1 fois.

VINDICATORs
Messages : 53
Inscription : 24 mars 2015, 14:38

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par VINDICATORs » 27 janvier 2019, 09:33

Là d'accord, mais si tu fais de simple modifications comme ajouter une option dans les fichiers de conf /etc/sysconfig/network-script/ifcfg-eth1 (par exemple), il se mélange les pinceaux.

Et comme les gens ne connaissent même pas nmcli (bah vi...), ils utilisent toujours ce genre de modification direct autant manuellement, que dans leurs scripts, templates...

C'est aussi parfois le comportement de nmtui qui provoque le même genre de chose (pas sur des versions plus récentes de NetworkManager il me semble, mais pas sous la 7.6 vu que je reproduit le problème que ce soit avec CentOS ou RHEL...).

D'ailleurs il reprend souvent la configuration avec une des UUID d'un fichier dhclient-....state.

Donc à part faire une purge manuel ou de désactiver la carte/supprimer/recréer il n'y a pas d'autres solution?

Bizarre pour un truc soit disant dynamique...

Après il me semble ne plus être tombé sur ce cas depuis fort longtemps sous Fedora. Après test sur Fedora 29 je ne reproduit pas ce problème autant manuellement qu'avec nmtui.

Beta-Pictoris
Messages : 1017
Inscription : 07 janvier 2014, 21:48
Localisation : Angers, France

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par Beta-Pictoris » 27 janvier 2019, 13:53

Si tu modifies les network-scripts, tu dois le signaler à Network-Manager:

Code : Tout sélectionner

nmcli connection reload
Voir ici: https://access.redhat.com/documentation ... Files.html

VINDICATORs
Messages : 53
Inscription : 24 mars 2015, 14:38

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par VINDICATORs » 28 janvier 2019, 19:39

C'est ce que l'on faisait avec le collègue, mais on vient d'apprendre après analyse que ce n'était pas le cas de l'équipe d'en face... Du coup on en revient au même point.


En fait leur playbook rajoute des options dans le fichier ifcfg-ethX et relance le service sans passer par cette étape. Du coup on ce retrouve donc avec des incohérences.

J'ai refais une manip pour corriger le problème, mais bon je commence à avoir des doutes...

Fin bref cette histoire de refaire des manipulations derrières explique pourquoi nous n'arrivons pas à reproduire l'incohérence après être passé dessus, même en forçant.

Et pourtant nous avons des "Experts" en face...

Beta-Pictoris
Messages : 1017
Inscription : 07 janvier 2014, 21:48
Localisation : Angers, France

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par Beta-Pictoris » 28 janvier 2019, 21:34

Les soi-disant experts d'en face devraient retourner en formation pour mettre à jour leurs connaissances.

Centos 7 n'est pas une Centos 6. Sa sortie, il y a, déjà, 4 ans, a apporté des changements majeurs: systemd, network-manager, firewalld,...

S'ils veulent rester conservateurs, ils devraient travailler avec de la debian.

Tu devrais leur dire de lire la doc redhat: https://access.redhat.com/documentation ... e_linux/7/

VINDICATORs
Messages : 53
Inscription : 24 mars 2015, 14:38

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par VINDICATORs » 28 janvier 2019, 22:18

Y a de l'expert qui vient de chez eux dans le lot... Après il y a beaucoup de conservatisme, même des jeunes ne connaissent pas la commande nmcli.

Je passe pour un extraterrestre... Mais bon. Enfin bon on attends de récupérer le bébé pour remettre de l'ordre, parce que c'est une catastrophe comment le projet fut préparé.

Fin bref... J'ai quand même reproduit le défaut sous CentOS identique 7.4 et 7.6. J'ai aussi eu ce point bloquant à une époque lointaine lorsque l'on est passé de Network à NetworkManager... (pitain me fait trop vieux pour ces conneries) Mais bon je me souvient plus de comment on résolvait ce genre de soucis à part virer le service network...
Là en fait une partie est géré par network classique et l'autre par NetworkManager, ce qui n'aide pas.

Après le bogue que j'ai mis se rapporte à la future Redhat 8 du coup... ce genre de comportement est toujours possible...

D'ailleurs DNF redevient Yum pour pas perdre les gens, mais c'était ce qui était prévu à l'origine.

VINDICATORs
Messages : 53
Inscription : 24 mars 2015, 14:38

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par VINDICATORs » 31 janvier 2019, 19:50

Bon je reviens sur le sujet.

A force de corriger les conneries j'en ai découvert une sans savoir trop d'où elle vient.

deux machine avec un sous réseau en /27 sur l'une et /32 sur l'autre...

Mais bon je constate qu'ils ont encore réussi à créer ce paradoxe avec 2 machines avec le même eth, mais en double uuid et configuration différente... Du coup... je me dis que leurs procédure d'installation du produit qu'ils installent ne gère pas la configuration réseau correctement. Mais bon je ne sais plus quoi dire.

Je vois qu'il ne semble pas y avoir de solution que d'attendre qu'ils aient fini et de corriger au fur et à mesure...
:oops: :oops: :oops: :oops: :oops:
Après les tests une fois fixé la méthode de modification des paramètres, plus de problèmes de mon coté.

VINDICATORs
Messages : 53
Inscription : 24 mars 2015, 14:38

Re: NetworkManager erreur bizarre, solution actuel pénible...

Message par VINDICATORs » 20 mars 2019, 10:06

Un peu de nouvelle de ce problème.

Du coup c'était bien des modifications en douces faites par "Personne" (désigne une vrai personne ou script lancé sans trop savoir ce qu'il fait).

Maintenant que "Personne" ne s'amuse à modifier en douce il n'y a plus de souci. Même si c'était le cas nous avons ce qu'il faut pour corrigé (à défaut de mettre des baffes) rapidement.

A mon avis il y a bien des méthodes de travail à revoir pour l'exploitation de NetworkManager. Mais comme souvent il y du réfractaire dans le lot c'est souvent compliqué...

Enfin bref... Cette partie est enfin terminé.

Répondre