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?
mark
On 18 May 2015 at 20:10, m.roth@5-cent.us wrote:
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?
nmcli radio wifi off
James Hogarth wrote:
On 18 May 2015 at 20:10, m.roth@5-cent.us wrote:
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?
nmcli radio wifi off
Thanks muchly. Wonder why it was installed with that enabled... you'd think anaconda would notice there was no wifi adaptor.
mark
On Mon, 18 May 2015, James Hogarth wrote:
On 18 May 2015 at 20:10, m.roth@5-cent.us wrote:
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?
nmcli radio wifi off
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.
Regards,
On 19 May 2015 11:40, me@tdiehl.org wrote:
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:
https://www.hogarthuk.com/?q=node/8
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.
On 5/19/2015 10:24 AM, James Hogarth wrote:
On 19 May 2015 11:40, me@tdiehl.org wrote:
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:
https://www.hogarthuk.com/?q=node/8
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
Kirk Bocek wrote:
On 5/19/2015 10:24 AM, James Hogarth wrote:
On 19 May 2015 11:40, me@tdiehl.org wrote:
Or if you want a bigger hammer:
systemctl disable NetworkManager.service systemctl enable network.service systemctl stop NetworkManager.service systemctl start network.service
To respond to this, my manager wants us to deal with 7 the way that is recommended, so the smaller hammer worked well. <snip>
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:
https://www.hogarthuk.com/?q=node/8
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.
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.
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.
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...<thinking> 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? <snip>
mark "they sound like ham call letters"
On 5/19/2015 10:54 AM, m.roth@5-cent.us wrote:
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...<thinking> 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?
<snip>
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 "10.0.0.1/24" ipv4.dns "10.0.1.1, 10.0.1.2" ipv4.gateway 10.0.0.254
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:
On 5/19/2015 10:54 AM, m.roth@5-cent.us wrote:
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...<thinking> 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?
<snip>
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 "10.0.0.1/24" ipv4.dns "10.0.1.1, 10.0.1.2" ipv4.gateway 10.0.0.254
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.
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.
mark
On 5/19/2015 12:54 PM, m.roth@5-cent.us wrote:
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.
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.
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...<thinking> 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?
<snip>
mark "they sound like ham call letters"
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
We have licensed software, using flexlm, whifh chokes and pukes, unless it is able to communicate on eth0, so I have to jump through hoops to ensure the correct interface IS eth0.
Until they fix this issue, I have no choice.
-chuck
device names are all kernel and udev. nothing to do with network manager.
if you want to get predictable interface names, set up udev rules appropriately.
https://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html
-
Chuck Campbell -
James Hogarth -
Kahlil Hodgson -
Kirk Bocek -
m.roth＠5-cent.us -
me＠tdiehl.org