There are enormous changes when upgrading from RHEL 6 to 7 (Red Hat Enterprise Linux). It’s not that Red Hat decided to change almost everything. Several different communities working on different projects have independently made significant RHEL 7 changes. These occurred between the release of RHEL 6 in November, 2010, and the release of RHEL 7 in June, 2014.
I have described many different aspects of systemd and the new Linux journal logging system, those are part of the RHEL 6–7 migration. A series of posts describing the Linux booting chain covered UEFI, UEFI – shim, GRUB Loader, the role of the kernel, and how systemd has replaced init. We also covered how to transition from systemd from init and service control. How to configure the new journal daemon and how to extract journal entries was also looked at.
This week I’m starting a series of articles on other major changes and new features you will encounter not just in Red Hat but in all other recent distributions.
Things used to be so simple. Linux Ethernet interfaces were named
eth2, and so on.
But then we got the “everything at once” approach of systemd. Couple that with the kernel’s automatic probing and discovery of hardware and we can no longer rely on devices being discovered in the same order every time. Interfaces
eth1 might swap names after the next reboot.
Where’s the harm? Remember that a network is configured in a file named
ifcfg-name in the directory
/etc/sysconfig/network-scripts. If they trade names, they trade configurations and each is effectively plugged into the wrong network.
On my OpenBSD laptop where I’m writing this, my wired Ethernet and wireless interfaces are named
run0, respectively. OpenBSD names interfaces by driver and discovery order. The wired Ethernet has a Realtek 8101E chipset recognized by the
re kernel module, and the wireless has a Ralink RT3070 chipset recognized by the
run kernel module. So,
run0 for the first interfaces detected by those modules. Solaris does something very similar.
However, two Ethernet interfaces on the same system very likely use the same chipset and are recognized by one kernel module, so we’re back to the problem of the race condition. Which is
re0 and which is
Red Hat has linked MAC address to IP configuration for some time, leading to untold amounts of frustration over mysterious failures when you replace an Ethernet card with another card of the same model plugged into the same slot.
Their NetworkManager system has used its own database of UUID assignments which seems to be based at least partly on the MAC address and which can be even more mysterious and frustrating. Let’s not go that way.
A project started by the freedesktop.org group devised a naming system that will be consistent from one boot session to the next. The names all start with
en for Ethernet or
wl for wireless LAN. These are followed by one of:
eno2for the first and second on-board Ethernet.
ens2for the first and second PCIe hotplug Ethernet.
enp2s0for an Ethernet interface at PCI bus address 02:00.0. That’s bus #2, slot #0, the first (.0) function of the card in that slot.
p0s3part comes from the PCI address of the USB controller,
f1u4from the USB device addressing.
enx0011951E8EB6for the device with MAC address 00:11:95:1E:8E:B6.
This system provides consistent names. Sure, the names aren’t what we’re used to, but how human-friendly was something like
My experience is that I can’t predict whether an interface embedded on the motherboard will get named
enpXsY. And if I plug a card into a PCI slot, I have no idea as to which bus and slot that will be without reading the motherboard documentation. But I can easily figure out either situation with a little observation and experimenting.
We get into this in the newly revised Linux server administration course The new revision of it, based on RHEL 7, will begin running in a few weeks. Learning Tree has also introduced a new 1-day course you can take on-line entitled Linux Booting & Initialization.
And guess what — all of the network commands have changed, too! I’ll explain that next time, check back then.