Désactivation de NetworkManager sur RHEL 7


9

Je configurais un serveur RHEL7 dans vmware vSphere et j'ai du mal à l'obtenir sur le réseau sans NetworkManager. J'ai configuré le serveur pour avoir une adresse IP statique pendant le processus d'installation et il a tout configuré à l'aide de NetworkManager. Bien que cela fonctionne, nous n'utilisons pas NetworkManager dans mon bureau, alors je suis allé saisir ce que nous mettons habituellement le fichier de configuration pour mettre les serveurs RHEL6 en ligne sans NetworkManager.

/ etc / sysconfig / network-scripts / ifcfg-ens192 est le suivant:

NOM = ens192
TYPE = Ethernet
ONBOOT = oui
NM_CONTROLLED = non
BOOTPROTO = statique
IPADDR = 10.0.2.15
PREFIX = 24
GATEWAY = 10.0.2.2

Cependant, lorsque je désactive NetworkManager, le service réseau ne démarre pas avec l'erreur suivante

#service network restart

Redémarrage du réseau (via systemctl): le travail pour network.service a échoué. Voir «systemctl status network.service» et «journalctl -xn» pour plus de détails.

Et les deux commandes produisent les informations suivantes:

réseau [1838]: réponses RTNETLINK: fichier existe
réseau [1838]: réponses RTNETLINK: fichier existe
réseau [1838]: réponses RTNETLINK: fichier existe
réseau [1838]: réponses RTNETLINK: fichier existe
réseau [1838]: réponses RTNETLINK: fichier existe
réseau [1838]: réponses RTNETLINK: le fichier existe
réseau [1838]: réponses RTNETLINK: le fichier existe
systemd [1]: network.service: processus de contrôle terminé, code = état quitté = 1
systemd [1]: impossible de démarrer LSB: apporter mise en réseau haut / bas

En outre, voici ce que la commande «ip addr» génère:

1: lo: mtu 65536 état de file d'attente qdisc Lien inconnu
     / bouclage 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
     inet 127.0.0.1/8 hôte de portée lo
       valid_lft forever
     prefered_lft forever prefer_lft forever inet6 :: 1/128 scope host
       valid_lft forever prefer_lft forever
2: ens192: mtu 1500 qdisc noop state DOWN qlen 1000
     link / ether 08: 00: 27: 98: 8e: df brd ff: ff: ff: ff: ff: ff


RTNETLINK answers: File existssignifie que tout ce qui a network.serviceessayé d'ajouter (probablement des adresses IP) était déjà là. Exécutez ip addret ajoutez les résultats à votre question.
BenjiWiebe

J'ai récemment débogué un problème avec network.serviceet la meilleure façon de suivre les commandes ip était strace. Vous ne devriez généralement pas obtenir ce type d'erreur. Cela peut valoir la peine d'être signalé (idéalement via le support).
Pavel Šimerda

Réponses:


2

Vérifiez votre adresse MAC pour la machine virtuelle. Il devrait être 08: 00: 27: 98: 8e: df puisque c'est ce qui est montré que vous avez exécuté ip addr. Si c'est autre chose, vous devrez le définir dans votre fichier ifcfg-ens192 avec ce qui suit, mais remplacez l'adresse par la réelle.

HWADDR="08:00:27:98:8e:df"

J'ai eu le même problème et cela l'a résolu pour moi.


Le fichier de configuration dans la question repose apparemment sur NAME = ens192 sans correspondance d'adresse MAC.
Pavel Šimerda

1

Tout ce que j'ai trouvé, c'est que MAC dans la configuration

 NAME=ens192
 TYPE=Ethernet
 ONBOOT=yes
 HWADDR="08:00:27:98:8e:df"
 NM_CONTROLLED=no
 BOOTPROTO=static
 IPADDR=10.0.2.15
 PREFIX=24
 GATEWAY=10.0.2.2

Si vous n'êtes pas sûr de l'adresse matérielle, vous pouvez la trouver dans.

 cat /sys/class/net/ens192/address

1

Essayez d'accéder aux paramètres réseau de la machine virtuelle et assurez-vous que le câble réseau est connecté et vérifiez si vous l'avez bloqué avec un pare-feu.


0

vous devez mettre ces informations (GATEWAY = 10.0.2.2) dans / etc / sysconfig / network une fois cela fait, le redémarrage du service devrait réussir


0

J'ai également rencontré l'erreur "Échec du démarrage de LSB: Bring up / down networking", depuis la désactivation de NetworkManager. Il a fallu deux minutes pour afficher les interfaces après le démarrage. La cause de la confusion était "... LSB". Il s'est avéré que le message provient uniquement du script /etc/rc.d/init.d/network traditionnel. Dans mon cas, la suite a résolu le problème;

À network-scripts / ifcfg-eth0 ajouté

NMCONTROLLED=no

Suppression des fichiers ifcfg- * inutiles que NetworkManager a laissés

# rm /etc/sysconfig/network-scripts/ifcfg-Wired_connection_?

0

Cela résoudra le problème!

# rm /etc/udev/rules.d/70-persistent-ipoib.rules 

# reboot
  • Maintenant, éditez / etc / sysconfig / network-scripts / ifcfg-eth0,
  • Ajouter un nouveau HWADDR généré ou le supprimer
  • Supprimer la ligne UUID

-Redémarrez le service de mise en réseau

 #systemctl restart network.service

MAINTENANT! Travail.


0

NetworkManager dicte la route par défaut (route ip) même si votre interface a nm désactivé, c'est juste cette interface et non le système entier.

ps aux | grep -I net   # will probably find NetworkManager still running.
chkconfig network on
systemctl disable NetworkManager.service
systemctl stop NetworkManager.service

1
systemctl disablen'arrête pas un service, ce chkconfig ... offqui ne se traduit pas de toute façon par la même commande.
Pavel Šimerda

-1

J'avais le même problème. Je supprime donc les fichiers de sauvegarde que j'ai créés /etc/sysconfig/network-scripts, tels que ifcfg-Bridge_connection_1.homeet ifcfg-Bridge_connection_1.officeque j'ai créés pour la sauvegarde. Ils ne devraient pas y être créés. Le /etc/init.d/network restartpourrait bien fonctionner après supprimer les ifcfg- inutiles *.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.