This is the kind of frustration that gives rise to new open-source
projects (or at least did in a by-gone era). How badly do you want this
fixed?
You are correct, the art of the command-line is disappearing. Systemd on
7 is painfully rubbish.
Thanks for sharing your trials and tribulations. It made my morning to
commiserate.
Good luck!
On 04/08/17 22:59, Nico Kadel-Garcia wrote:
On Sat, Apr 8, 2017 at 5:36 PM, ~Stack~ <i.am.st...@gmail.com> wrote:
Greetings,
I will spare the details, but suffice to say I am in a position where
after many years knowing the 'network' commands I've been tasked to
learn nmcli much better than I do now. This is all on SL7.
Oh, you poor beggar. I feel your pain. Notes that I published years
ago for CentOS 5 and CentOS 6 pair bonding just went obsolete, in
completely undocumented and unintelligible ways, with upstream RHEL 7
and Fedora's fascination with "NetworkManager" instead of anything
stable or scriptable. I feel your pain a *lot*.
I've been reading documents, building and tearing down networks for
hours, and trying to put into practice what I'm learning (still a long
way to go; haven't touched the infiniband parts yet). Something keeps
coming up in documentation that bothers me.
Here is an example of one of *many* documents:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Network_Configuration_Using_sysconfig_Files.html
They mention taking down a network with:
$ nmcli dev disconnect interface-name
but bringing it up with:
$ nmcli con up interface-name
That is so infuriating to me. Why use different sub-commands? Especially
when there exist subcommands in the same context? Why not do this?
$ nmcli dev disconnect interface-name
$ nmcli dev connect interface-name
Because they're trying to weld NetworkManagers's graphical interface,
on top of poorly integrated command line interface, on top of the
actual underlying bash scripts that do the real work. It's Fugly Out
There(tm). NetworkManager for RHEL 7, and thus for CentOS 7, even
introduced the concept of parsing multiple infividual ifcfg-* files to
manage the same actual device, such as multiple file to manage
ifcfg-eth0 in ifcfg-eth0 and ifcfg-ethp-slave. The result is madness.
In case it's unclear I am *not* happy with NetworkManager for servers
or stable environments. Laptops that have to wander from environment
to environment need multiple VPN's, yeah, OK, I can see having a more
complex tool. But for a VM? Or a server?
I'd like to introduce you to wone of my favorite settins for
/etc/sysconfig/network-scripts/ifcfg-* files, or even for
/etc/sysconfig/network, or if you feel really paranoid, /etc/profile.
NM_CONTROLLED=no
Turn *off* NetworkManager manipulation for anything that doesn't need it.
Or even this?
$ nmcli con down interface-name
$ nmcli con up interface-name
As far as I can tell, they are both doing the same thing. In fact the
only difference I can tell comes from the nmcli help documentation where
it says the difference is in the auto-activating:
$ nmcli d disconnect --help
<snip>
The command disconnects the device and prevents it from auto-activating
further connections without user/manual intervention.
$ nmcli connection down --help
<snip>
Deactivate a connection from a device (without preventing the device
from further auto-activation). <snip>
If it was just one document, then whatever. But I've seen that in
several of the RH documents as well as on several blogs/webpages. What
am I missing? What is the difference and why should I prefer to take
down a connection with "device disconnect" but bring it up with
"connection up"?
See above. NetworkManger is a complex management layer un top of the
actual "ifconfig" tools managed by the various
/etc/sysconfig/network-scripts, and for many operations it simply adds
instability and confusion.
Thank you!
~Stack~
