On Sat, Apr 8, 2017 at 10:59 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> On Sat, Apr 8, 2017 at 5:36 PM, ~Stack~ <[log in to unmask]> wrote:


>> 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*.

You follow federo-devel@, so you must've seen one/two/three years a
post by one of the RH developers who works on the core packages of
Fedora saying that they didn't want to keep on maintaining the scripts
in "/etc/sysconfig/network-scripts/". Between that lack of interest
and the desire to have the network be handled dynamically by a daemon,
it wouldn't be surprising if a future RHEL8 or RHEL9 drops the
"/etc/sysconfig/network-scripts/" infrastructure.

It's unfortunate that distributions have always had an NIH attitude to
network management (other than NM and systemd-networkd). From the ones
that I use:

- Debian and Ubuntu have "/etc/init.d/networking", "/etc/network/*",
and "/sbin/if{up,down}" (the latter being compiled executables)

- Fedora and RHEL have "/etc/rc.d/init.d/network" and
/etc/sysconfig/network-scripts/*"

- Funtoo has "/etc/init.d/netif.tmpl", "/etc/netif.d/*", and
"/etc/conf.d/netif.<nic_name>"

- Gentoo has "/etc/init.d/net.lo", "/lib/netifrc", and "/etc/conf.d/net"

- Slackware has "/etc/rc.inet{1,2}" IIRC (I had to manage some
Slackware servers for a few months two years ago so I might be
misremembering the script names)

:(


>> 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).

"nmcli conn ..." is for managing a network connection (ip addresses,
routes, nameservers, bonding/bridging/tagging) so you can bring down
the connection with "nmcli conn down ...".

The difference between "nmcli conn down ..." and "nmcli dev disconn
..." is that the latter prevents the connection from being
auto-activated.


> 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?

The lead NM developer's replied to you on fedora-devel@ or
fedora-user@ in the past that he and his fellow NM developers have
worked hard to add to NM configuration options for complex server
setups as well as a cli tool for managing settings. Sadly, NM seems to
be a project that can do nothing right in the eyes of its users even
though it's left the flakiness of its early years behind.


> 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.

I prefer to delete ifcfg-* files and use NM keyfiles. For a bridge:

# cd /etc/NetworkManager/system-connections

# cat bridge0-master
[connection]
id=bridge0-master
type=bridge
uuid=84eaf7e7-a020-481b-9709-28892d61701c
[bridge]
interface-name=bridge0
stp=false
[ipv6]
...
[ipv4]
...

# cat bridge0-en0
[802-3-ethernet]
mac-address=28:d2:44:0e:2f:53
[connection]
id=bridge0-en0
master=84eaf7e7-a020-481b-9709-28892d61701c
slave-type=bridge
type=802-3-ethernet
uuid=0617b1c0-becb-4921-905b-a70d2e61e12d

That way there's no confusion between the use of "network.service"
config files and "NetworkManager.service" config files. And there's no
need to learn nmcli commands.


>> 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>

I should've read this before writing the above :(


>> 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"?

What I wrote and Nico's help output explain it.