Anselm Lingnau <[email protected]> wrote: > Perhaps we should instead have a weight-6 “Basic Network Configuration and > Troubleshooting” objective that concentrates on iproute2, ping, traceroute, … > and a weight-2 “High-Level Network Configuration” objective that could cover > things like NetworkManager and systemd-networkd on an “awareness” level. > (Adjust the weights to taste.)
Unfortunately, that's a can-o-worms. Ergo ... (see the latter part of this post) To start, I'm adding in Okada's response (very glad he went here) ... Okada Kenji <[email protected]> wrote: >> 2017/11/10 4:55、Bryan Smith <[email protected]>のメール: >> Correct, which is why if Debian deprecates something -- like it did >> net-tools (e.g., ifconfig) in 2009 in favor of iproute (e.g., ip addr) >> -- it's likely something LPIC should consider doing as well. > > Hi. > I strongly agree this idea. My main using distribution, Debian, is using > ‘ip’ command as default since last time. It may means LPIC should be reducing > the weight of net-tools (like ifconfig) and increasing the weight of ‘ip’ > command. > (I still love old net-tools commands like ifconfig, route, netstat and so on). Indeed. The net-tools and legacy scripts (e.g., ifup/ifdown) have stuck around, and even been modified to use ip, nmcli, ss, et al., because people are not learning the iproute2 stack and command set. At the same time ... Ysing 'static' scripts that aren't able to deal with dynamic stacks -- everything from libvirt, Kubernetes and solutions built around them -- is the real issue. The #1 issue I consistently ran into, and why we're seeing all these new *d/*ctl commands, etc... So, again, I always fall back to learning the "base toolsets" that work with these "newer developments." Which brings me to ... Okada Kenji <[email protected]> wrote: > On last releasing of Ubuntu,17.10, they set Netplan for network configuration > as > default. LPIC might need the topic of Netplan in (not now but near) future. I purposely _avoided_ bringing up Netplan ... Just like I was trying to _not_ detail the full purpose of nmcli (NetworkManager Command Line Interface). ;) Although at least when people bring up "Netplan," _unlike_ nmcli, it doesn't cause assumptions (quite _false_ assumptions) to be made. BUT ... since we've now "gone here" ... nmcli _is_ for _servers_, _not_ just notebooks ** It's _not_ just a "GUI tool" I hope everyone [now] understand this. Why? Again ... cloud like IaaS virtualization, devops like PaaS containers, do _not_ work with static scripts. Something "dynamic" was necessary ... just like firewalld ... just like a lot of things. ;) E.g., ever try to run static if* scripts or ip* scripts when the underlying network infrastructure (IaaS) or scale-out server instances (PaaS)? You will pull your hair out if you try to run legacy scripts. Side Note (experience): I worked in very early enablement/consulting (2012-2016), all 100% post-sales (I.e., I got "stuck with the check" at customers/partners) of KVM in oVirt (RHEV) and OpenStack (both RHEL and HP Debian) IaaS, OpenShift (on RHEL) or CloudFoundry (on HP hLinux) PaaS, etc... When you deal with constantly changing network infrastructure, static scripts will make you pull your hair out. So ... now we can talk about "NetPlan" ... NetPlan is another layer that can manage both NetworkManager, systemd-network and even some legacy services. In-a-nutshell (mega-oversimplification), it is really the "drop in solution" that can read existing Debian "interface" files, like Red Hat's nmcli stack can be the "drop in solution" that can read existing Fedora "network-scripts" files. Underneath it all, it's still using "ip" commands, along with the option to support NetworkManager, as well as systemd-network, etc... Which is the can-o-worms we're looking at, as LPI. It's going to be easy to get overloaded, which is why I was _avoiding_ a lot of this (for a reason). ;) - bjs **P.S. Again ... Anselm Lingnau <[email protected]> wrote: > (Seriously, NetworkManager has its uses – especially for laptops that get > moved around a lot – but it is (a) way too baroque to teach in anything > approaching its entirety and (b) practically self-explanatory for the simple > use cases that 80% of NM installations need to deal with.) nmcli is the CLI tool for configuring _dynamic_ server environments, especially IaaS and PaaS. E.g., you, the sysadmin, are _not_ using nmcli so much as the various IaaS, PaaS and other environments have scripts -- when they aren't making API calls to NetworkManager directly -- and are running nmcli on servers for you. ;) I.e., NetworkManager is a _service_ that is ... - IaaS: called by libvirtd (various virtualization) via either API or via nmcli commands - PaaS: called by Kubernetes (container orchestration) via API or via nmcli commands - Etc... It's not just a "GUI tool." Yes, there is a "GUI applet" for notebooks. But NetworkManager is designed for _dynamic_ server needs. Today's NetworkManager is not your father's GUI tool. ;) -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
