In the primary article of this sequence, Get started with NetworkManager on Linux, I checked out what NetworkSupervisor does and a few of the instruments it offers for viewing community connections and units. I mentioned utilizing the nmcli command to view the standing of community units and connections on a bunch. I additionally talked about that NetworkSupervisor doesn’t want interface configuration information for many hosts. However, it may well create its personal INI-style connection configuration information, and it acknowledges the older and now deprecated community interface configuration information.
This article explores three questions:
- Why do I not use interface configuration information?
- Why do I exploit interface configuration information?
- Why do I exploit the outdated community interface configuration information?
Sound complicated? Read on.
My community philosophy
I discuss philosophy rather a lot. I even wrote a guide, The Linux Philosophy for SysAdmins, which has tenets that apply to the design and construction of computer systems, working programs, and networks. I will not bore you with all the main points, however there are some issues to think about when designing–or redesigning–a community.
As a “Lazy SysAdmin,” I prefer to “Find the Simplicity”–sure, these are two of the tenets–and create a sublime community design. This is not only in regards to the bodily design and structure of the community parts and wiring, though the perfect, most elegant, and best networks to work on are properly laid out bodily and look good. However, this dialogue is in regards to the logical construction of the community.
Why I do not use interface configuration information?
I do not use interface configuration information on my community largely as a result of every host is dynamically configured at boot time utilizing the Dynamic Host Configuration Protocol (DHCP) server. This permits centralized configuration and administration of some computer systems as much as lots of and even hundreds of programs. The backside line is that each one the configuration information obligatory for every host is saved within the DHCP configuration file, /and so on/dhcp/dhcpd.conf, the place it’s centrally managed.
I impose simplicity on my community by utilizing instruments that present central administration for many of the related hosts–all apart from hosts that work as routers and supply server providers. The thought is that utilizing DHCP to offer the entire community configuration information wanted by many of the community hosts simplifies my job and permits me to be the “Lazy SysAdmin.” Suppose one thing modifications on the community, such because the IP handle to the default gateway or the first identify server? Changing that data in a single location, the dhcpd.conf file, is far much less work than altering a static configuration on ten or a thousand hosts.
NetworkSupervisor doesn’t want native configuration information when DHCP offers the community configuration data. By default, all Fedora and Red Hat hosts receive their community configuration from a DHCP server. This makes putting in new hosts on a community simple and easy. All you want is a DHCP server.
For most networks with a single host, reminiscent of in a house workplace with one or two laptops and some different units, the wi-fi router supplied by the ISP accommodates the DHCP server required to supply an entire set of configuration information to all of your units. The router’s DHCP server offers the community configuration information even when you use the 4-port wired change on the again of most wi-fi routers to attach a wired desktop laptop.
Why I do use interface configuration information?
Most of my community hosts do not want static community configurations and use DHCP.
However, there are two hosts on which I do use static community configuration: My community server–the one which runs the DHCP server–and the Linux host I exploit for my community/firewall. These two hosts are finest configured utilizing static setups that do not rely on exterior configurations.
Think about this for a minute. If the DHCP server should have an IP handle to ship community configuration data, together with an IP handle, to itself… Well, that simply will not work—type of the community equal of the rooster and egg state of affairs.
DHCP shoppers request community configuration utilizing a broadcast on the community, and the server responds to that request utilizing the MAC handle of the requesting consumer. The DHCP server can’t even be a DHCP consumer, so this simply will not work.
Even if utilizing the DHCP server to set its personal IP handle–and different community configuration attributes–might be made to work, the entire suggestions I see on the Internet counsel that it could be a very horrible thought and that no good administrator would even take into account doing such a factor.
The Linux host I exploit for a router and firewall has 4 community interfaces, three of that are at the moment energetic, and one on the motherboard, which is flawed. It additionally has a set of forwarding and routing guidelines that should all the time be constant. This configuration is finest handled utilizing static community settings.
For instance, one interface on my router connects to the WAN facet of my wi-fi router. The wi-fi router offers an inside DHCP server for hosts related to its LAN and WiFi facet however relies upon upon both static or DHCP configuration on the WAN facet. So I configure each the WAN facet of the wi-fi router and the NIC that connects it to my Linux router utilizing a static setup.
Another interface on that Linux router connects to the surface world by way of a static IP handle supplied by my ISP. If I set that interface to be configured by DHCP, the ISP’s router would serve it one of many remaining different IP addresses within the eight-address block I’ve been assigned.
Any sort of static community configuration, versus DHCP, requires community configuration information.
Why I nonetheless use the outdated fashion ifcfg-<interface-name> information
The reply to that is actually easy. I simply haven’t gotten round to creating the change. These information are situated within the /and so on/sysconfig/network-scripts listing, and–thankfully for me–NetworkSupervisor will nonetheless seek for and use these if it has none of its personal community connection information. There will not be any community connection information as a result of they don’t get created mechanically, and I’ve not wanted to create them.
I intend to make the change in Part 3 of this sequence and convey my community as much as present configuration practices. For now, nevertheless, it’s nonetheless a good suggestion to know in regards to the old-style community configuration information as a result of there are nonetheless a variety of them round.
What I’ve now
I’ll evaluate the present state of the community on my router. Aside from the native loop (lo)–which is all the time current on Unix and Linux hosts–this host at the moment has three energetic community interface playing cards (NICs). Due to the issues with the on-board NIC described in Part 1 of this sequence, I deactivated it in UEFI/BIOS of this host in order that it not exhibits up. I’ve additionally disabled IPv6 on my community as I do not want it.
The following is the nmcli command exhibiting the state of the NICs on my router/firewall host:
[root@wally ~]# nmcli
np4s0: related to enp4s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:04:44:03, hw, mtu 1500
ip4 default
inet4 45.20.209.41/29
route4 45.20.209.40/29 metric 102
route4 default by way of 45.20.209.46 metric 102
enp1s0: related to enp1s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:03:E9:89, hw, mtu 1500
inet4 192.168.10.1/24
route4 192.168.10.0/24 metric 101
enp2s0: related to enp2s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:03:FD:85, hw, mtu 1500
inet4 192.168.0.254/24
route4 192.168.0.0/24 metric 100
lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: 192.168.0.52 8.8.8.8 8.8.4.4
interface: enp4s0
servers: 192.168.0.52 8.8.8.8
interface: enp2s0
servers: 192.168.0.52 8.8.8.8
interface: enp1s0
Each of those NICs has an interface configuration file within the /and so on/sysconfig/network-scripts/ listing. This is as a result of they have been initially put in at a time when NetworkSupervisor—or the sooner community service—created these information mechanically throughout set up. Since NetworkSupervisor continues to acknowledge these information, there isn’t a urgent want for me to do something completely different.
Interface configuration file naming
Fortunately, most of you missed out on a few of the enjoyable all us old-time sysadmins used to have when including, eradicating, or simply transferring the NIC {hardware} in hosts with a number of NICs. It appeared like the entire NICs would get renamed each time something modified. That meant I would wish to find out which identify every NIC was given and modify the interface configuration information to match the proper names.
There are actually very constant NIC naming conventions based mostly on the NIC’s logical place on the PCIe or USB information busses. This conference was created round 2009 to eradicate these issues.
How it really works–type of
The udev machine supervisor detects when a brand new machine has been added to the system, reminiscent of a brand new NIC, and creates a rule to establish and identify it if one doesn’t exist already. During the early a part of the startup part, the Linux kernel makes use of udev to establish related units, together with community interface controllers. At this stage, the units are nonetheless recognized by their conventional names of ethX. Shortly after that, systemd renames the units based on a sequence of hierarchical naming schemes.
I used my firewall system for example of a system with a number of community connections. You may also do that by yourself Linux hosts.
[root@wally ~]# dmesg | grep eth
[ 2.081738] r8169 0000:01:00.0 eth0: RTL8168e/8111e, 84:16:f9:03:e9:89, XID 2c2, IRQ 126
[ 2.081830] r8169 0000:01:00.0 eth0: jumbo options [frames: 9194 bytes, tx checksumming: ko]
[ 2.089218] r8169 0000:02:00.0 eth1: RTL8168e/8111e, 84:16:f9:03:fd:85, XID 2c2, IRQ 127
[ 2.089303] r8169 0000:02:00.0 eth1: jumbo options [frames: 9194 bytes, tx checksumming: ko]
[ 2.094383] r8169 0000:04:00.0 eth2: RTL8168e/8111e, 84:16:f9:04:44:03, XID 2c2, IRQ 128
[ 2.094467] r8169 0000:04:00.0 eth2: jumbo options [frames: 9194 bytes, tx checksumming: ko]
[ 2.142068] r8169 0000:01:00.0 enp1s0: renamed from eth0
[ 2.152128] r8169 0000:04:00.0 enp4s0: renamed from eth2
[ 2.161346] r8169 0000:02:00.0 enp2s0: renamed from eth1[root@wally ~]#
This instance exhibits that just a little over two seconds into the Linux startup sequence, the ethX community units have been situated, and fewer than a second later, they have been renamed enpXs0.
All present releases of RHEL, CentOS, and Fedora use the most recent NIC naming conventions. Most different distros additionally use this naming conference.
The NIC naming conference for these distributions is described intimately within the RHEL 7 doc, “Networking Guide,” with an evidence of how the names are derived. Using the NetworkSupervisor instruments to handle networking is roofed within the RHEL 8 doc, “Configuring and Managing Networking.”
The following is an excerpt from Chapter 11 of the RHEL 7 “Networking Guide”:
- Scheme 1: Names incorporating Firmware or BIOS supplied index numbers for on-board units (instance: eno1), are utilized if that data from the firmware or BIOS is relevant and out there, else falling again to scheme 2.
- Scheme 2: Names incorporating Firmware or BIOS supplied PCI Express hotplug slot index numbers (instance: ens1) are utilized if that data from the firmware or BIOS is relevant and out there, else falling again to scheme 3.
- Scheme 3: Names incorporating bodily location of the connector of the {hardware} (instance: enp2s0), are utilized if relevant, else falling straight again to scheme 5 in all different instances.
- Scheme 4: Names incorporating interface’s MAC handle (instance: enx78e7d1ea46da), just isn’t utilized by default, however is on the market if the person chooses.
- Scheme 5: The conventional unpredictable kernel naming scheme, is used if all different strategies fail (instance: eth0).
The major operate of the revised naming schemes is to offer a constant set of NIC names in order that putting in a brand new NIC and even only a reboot wouldn’t trigger the NIC names to alter. This by itself is properly definitely worth the modifications. I’ve had loads of alternatives to combat with the apparently random renaming of a number of ethX units on a single host. That was a lot much less enjoyable than studying the revised naming schemes.
Understanding interface configuration information
These interface configuration information are simple to create and modify. The following configuration information on my firewall/router host are all situated within the /and so on/sysconfig/network-scripts listing. This listing beforehand contained the entire scripts used to handle the community connections, however NetworkSupervisor has made them out of date. Only the deprecated interface configuration information may stay on this listing.
-rw-r--r-- 1 root root 381 Jan 11
2021 ifcfg-enp1s0
-rw-r--r-- 1 root root 507 Jul 27
2020 ifcfg-enp2s0
-rw-r--r-- 1 root root 924 Mar 31 14:24 ifcfg-enp4s0
This is the configuration file for the interface that connects the firewall host to my residence community, as you’ll be able to see from the remark:
[root@wally network-scripts]# cat ifcfg-enp2s0
# Interface configuration file for enp2s0 / 192.168.0.254
# This interface is for the inner community
# Correct as of 20220711
HWADDR=84:16:f9:03:fd:85
NAME="enp2s0"
TYPE=Ethernet
ONBOOT=sure
BOOTPROTO=static
IPADDR=192.168.0.254
PREFIX=24
DNS1=192.168.0.52
DNS2=8.8.8.8
DEFROUTE=no
PEERDNS=sure
PEERROUTES=no
IPV4_FAILURE_FATAL=no
This file is for a reasonably easy static configuration that gives the IP handle, the CIDR prefix, and two DNS server IP addresses. No default route (gateway) IP handle is specified as that’s configured in one of many different interface configuration information.
The code block under exhibits the interface configuration file for the connection from my Linux router to the ISP’s router. It makes use of one of many static IP addresses supplied to me by my ISP.
##############################################################################
# Interface configuration file for enp4s0 / 45.20.209.41
# This NIC was put in to avoid issues with motherboard NIC, eno1.
------------------------------------------------------------------------------
# This interface is for the WAN - the AT&T fiber optic exterior community
# Correct as of 20220711
##############################################################################
TYPE= "Ethernet"
BOOTPROTO="static"
NM_CONTROLLED= "yes"
DEFROUTE= "yes"
NAME=enp4s0
UUID="fa2117dd-6c7a-44e0-9c9d-9c662716a352"
ONBOOT= "yes"
HWADDR=84:16:f9:04:44:03
IPADDR=45.20.209.41
PREFIX=29
GATEWAY=45.20.209.46
DNS1=192.168.0.52
DNS2=8.8.8.8
DNS3=8.8.4.4
PEERDNS=no
IPv6INIT=no
IPv6_AUTOCONF=no
IPv6_DEFROUTE=no
Since I do not use IPv6 and have disabled it, I might delete the IPv6 assertion in each information.
Network configuration variables
The desk under lists the commonest community configuration variables, together with some temporary explanations for every. Many IPv6 choices are functionally equal to the equally named IPv4 ones. Local configuration variable settings override these supplied by a DHCP server. You can use DHCP for configuring a bunch however use an interface configuration file to override a number of of the DHCP configuration variables.
| Configuration variable | Description |
|---|---|
| TYPE | Type of community reminiscent of Ethernet or token ring. |
| PROXY_METHOD | Proxy configuration technique. “none” means no proxy is in use. |
| BROWSER_ONLY | Whether a proxy configuration is for browsers solely. |
| BOOTPROTO | Options are dhcp, bootp, none, and static. The “none” choice implies DHCP. |
| DEFROUTE | This interface is the default route for this host to the surface world. |
| IPv4_FAILURE_FATAL | If that is set to “no” failure to acquire an IPv4 connection is not going to have an effect on any try and make an IPv6 connection. |
| NAME | The interface identify, reminiscent of enp0s3. This ought to match the interface identify within the interface configuration file identify. |
| UUID | A Universally Unique Identifier for the interface. It is created with a hash of the interface identify. The HWADDR is an older technique of bonding the file to the {hardware} interface, and I’ve discovered that the UUID may be commented out or deleted with out points. |
| DEVICE | The identify of the interface to which this configuration file is sure. |
| ONBOOT | If sure, this begins the interface at boot (actually startup time). If set to no, the interface just isn’t began till a person logs in on the GUI or manually begins the interface. |
| HWADDR | The MAC handle of the interface. This is without doubt one of the extra vital fields within the file as it’s used to bond the file to the proper {hardware} interface. The UUID is a more moderen addition and will also be used, however the HWADDR was first and is extra broadly used. |
| DNS1, DNS2 | Up to 2 identify servers could also be specified. |
| USERCTL | Specifies whether or not non-privileged customers could begin and cease this interface. Options are sure/no. |
| IPADDR | The IP Address assigned to this NIC. |
| BROADCAST | The broadcast handle for this community reminiscent of 10.0.2.255. |
| NETMASK | The netmask for this subnet reminiscent of 255.255.255.0. Use both NETMASK or PREFIX however not each. |
| PREFIX | The CIDR prefix for the community reminiscent of 24. Use both NETMASK or PREFIX however not each. |
| NETWORK | The community ID for this subnet reminiscent of 10.0.2.0. |
| SEARCH | The DNS area identify to go looking when doing lookups on unqualified hostnames reminiscent of utilizing studentvm1 as an alternative of studentvm1.instance.com. |
| GATEWAY | The community router or default gateway for this subnet, reminiscent of 10.0.2.1. |
| PEERDNS | The sure worth signifies that /and so on/resolv.conf is to be modified by inserting the DNS server entries specified by DNS1 and DNS2 choices on this file. No means don’t alter the resolv.conf file. Yes is the default when DHCP is specified within the BOOTPROTO line. |
| IPv6INIT | Whether to initialize IPv6 or not. The default is sure. |
| IPv6_AUTOCONF | Yes means use DHCP for configuration of IPv6 on this interface. |
| IPv6_DEFROUTE | This interface is the IPv6 default route for this host to the surface world. |
| IPv6_FAILURE_FATAL | If that is set to “no” failure to acquire an IPv6 connection is not going to have an effect on any try and make an IPv4 connection. |
| IPv6_ADDR_GEN_MODE | Configure IPv6 Stable Privacy addressing. |
There are many extra configuration variables than are listed right here, however these are those which might be most incessantly used.
Final ideas
There are nonetheless loads of Linux hosts round that use the interface configuration information described on this article. Despite being deprecated, NetworkSupervisor nonetheless acknowledges these information and might use them to configure community interfaces. However, most trendy Linux programs use NetworkSupervisor, so no configuration information are wanted except they serve a particular use case, like a server or a router.
I’ve a number of hosts that require extra than simply the usual NetworkSupervisor configuration. For me, it has simply not been a precedence to alter from the outdated interface configuration information to the present connection configuration information utilized by NetworkSupervisor. To forestall future issues with my community, I want to modify to the NetworkSupervisor community connection information. The subsequent article on this sequence will describe how I make that change.
