Turning Off Wifi In CentOS 7

Home » CentOS » Turning Off Wifi In CentOS 7
CentOS 10 Comments

Someone else got the 7 pxe install going, and one thing that’s annoying is that NetworkMangler appears to be regularly trying to fire up the wifi.

On a workstation, in a wired environment. I just want to tell NM to knock it off….It’s Monday, and my searching isn’t going too well. Clues for the poor?


10 thoughts on - Turning Off Wifi In CentOS 7

  • James Hogarth wrote:
    Clues for

    Thanks muchly. Wonder why it was installed with that enabled… you’d think anaconda would notice there was no wifi adaptor.


  • Or if you want a bigger hammer:

    systemctl disable NetworkManager.service systemctl enable network.service systemctl stop NetworkManager.service systemctl start network.service

    The above will disable NetworkMangler and return control of the network to the scripts in /etc/sysconfig/network-scripts just like previous versions.


  • Of course that goes against the RH recommendations, works against you if you want to do RHCSA/RHCE at some point, and has a few other issues too…

    It’s that behaviour that lead me to write this recently:


    There is the right time to use the old network service. EL6 or a couple of very specific edge cases. Otherwise you are effectively hurting yourself to some extent.

  • Great post. I am just in the process of building my first CentOS 7 host and was wondering whether to use NetworkManager. You’ve swayed me. I’ve always disabled it on CentOS 6. Your point about these new funky device names is really good. I will miss my simple eth0 and eth1 but tech moves on.

    Definitely a learning curve with nmcli. Right now I’m at the “Argh!
    WTF!” phase but I’m sure I’ll get over it. I got over it with selinux once I made the decision to *not* to disable selinux on all my new CentOS 6 hosts.

    You should move your post onto the wiki.


  • Kirk Bocek wrote:

    To respond to this, my manager wants us to deal with 7 the way that is recommended, so the smaller hammer worked well.


    Excerpt I *still* see absolutely no use in an enterprise environment, where we’re *all* wired, even the laptops when folks bring them in. This improves throughput and security, of course.

    And that one drives me nuts. It breaks PXE boot kickstart builds. Maybe
    *you* have all same model systems from the same manufacturer; we’ve got boxen from… at least five or six manufacturers, of varying ages, from the 10+ yr old Altix 3000 from SGI, to the current one from SGI, to my 5 yr old Dell workstation, to some old Penguins and several Suns (soon to set, the sooner the better…). How do you deal with everything from em1 to ens3f0, which comes up *only* after you start to install…. In what conceivable way is this better than having your scripts know that eth0 (or even em1) is always going to be how to talk to the world?

    mark “they sound like ham call letters”

  • Okay, diving in where angels don’t know what the hell they are doing. (I
    would love for James to pipe in here.) *But*, it seems like in the section in his posting on setting up a fixed IP address (which is my immediate interest):

    nmcli conection modify connection.autoconnect yes ipv4.method manual ipv4.addr “” ipv4.dns “,” ipv4.gateway

    Does not reference an actual interface name and nmcli is figuring everything out for you. *Unless* he is using “connection” here as a euphemism for an interface.

    If “connection” is the actual string then a script would work regardless of host.

  • Kirk Bocek wrote:

    But that doesn’t address the interface name at all. That kind of naming, which I think goes back to Sun, was fine for Sun, because all their hardware was alike. It just doesn’t work for multiple vendors with frequently changing NICs and motherboards.


  • The names are needed for security in case of hardware failure in more complicated setups. Consider a scenario where you’ve got a linux box running your network and some services – one NIC goes to the customer (Guest) wifi access point, another goes to your local LAN, a third goes to your internet connection. If the boot order of the cards is Internet / Local LAN / Guest WiFi, and the second card goes out… the ethX naming scheme suddenly gives the guest wifi people access to your shared resources run by that linux box.

    Edge case, I know, but still.