On Sat, Apr 8, 2017 at 5:36 PM, ~Stack~ <[log in to unmask]> 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~
>