Stable Future

Network News

If you are running a RHEL-based firewall, you have to be prepared for several changes, the biggest of which relates to the packet filter. Officially, RHEL 8 nftables is the successor to iptables, which Red Hat is retiring. If you want to take it back out of retirement, you will still find the tools and kernel modules on the system, but you are well advised to reconsider this step: Red Hat is not replacing the outdated iptables without a good reason.

Nftables solves the problem that iptables, after 20 years in the kernel, has reached the end of its life. In 1998, iptables replaced the unpopular ipchains, which had replaced ipfirewall, or ipfw, not so long before.

Iptables was fine for the requirements of the time, but the iptables architecture in the kernel is unsuitable for today's requirements given network cards capable of 200Gbps and more. The kernel developers have long since used all sorts of hacks to squeeze the last bit of performance out of iptables. In cloud setups, iptables is often the component that limits throughput.

Nftables is the kernel developers' way to solve the problem. One of the solution's biggest advantages is that admins no longer have to deal with different userspace programs (iptables, ip6tables, ebtables, and many more). Nftables offers all functionality under a uniform interface.

Integration in firewalld is also provided; in other words, if you have been configuring your firewalls with firewalld, you will not need to learn new tricks. All that remains is the exciting question of whether nftables – whose incompatibility with iptables has long been considered the biggest vulnerability – will remain the state of the art for a while or whether it will be replaced in the near future by the Berkeley Packet Filter (BPF), which I discussed in detail in the previous issue [3].

The infamous network scripts found in /etc/sysconfig/networking in RHEL 7 are no longer there in RHEL 8. Now, only the network manager takes care of the interface configurations.

In RHEL 8, the Cockpit software is part of the standard scope. Cockpit, an alternative to Webmin, is an administration GUI developed in large part by Red Hat that enables access to the most important parts of the system configuration from your browser. The component can be disabled if desired; you have no obligation to use it (Figures 4 and 5).

Figure 4: Cockpit is officially a separate product, but Red Hat does most of the work.

Figure 5: RHEL 8 delivers the Cockpit web interface out the box, but if you don't want it, you don't have to use it.

Supercharged KVM and Docker

The Qemu KVM version 2.12 included with RHEL 8 provides support for various extensions that are often used in high-performance computing. The Q35 PC machine type, which effectively uses the PCIe features of Intel I/O Controller Hub 9 (ICH9) chipsets and newer, is included, as is better support for Nvidia GPUs.

Ceph can now be used as storage for KVM virtual machines (VMs) on all CPU architectures supported by RHEL 8. Virtual CPUs (vCPUs) can now be activated and removed without stopping the VM, and if you want to use UEFI within a VM, Qemu KVM now has a corresponding UEFI BIOS that makes this possible.

Red Hat does not want to deal with the topic of containers only in the context of OpenShift and the like but leaves no doubt that containers should be an integral part of RHEL  8. The way it is technically implemented, however, is likely to cause some frowns, especially among Docker aficionados.

Clearly, Docker's merits for containers under Linux are undisputed – to some extent, the company has taken the issue from the realm of the dead back to this world. However, it has also led to "containers under Linux" and "Docker" sometimes being used synonymously – and that's a thorn in Red Hat's side. On the one hand, all container implementations for Linux use the same kernel features (e.g., namespaces and groups), and, of course, Red Hat is involved in their development.

On the other hand, Red Hat cannot be interested in Docker dominating the Linux container market; therefore, Red Hat quickly developed its own container format and placed it under an open license, the Open Container Initiative (OCI).

In RHEL 8, Red Hat is now strongly pushing this format into the market and delivering the tools to do so, which – in the style of Docker – let you manage containers, build container registries, and even build containers yourself with three tools: Buildah, Skopeo, and Podman.

Container Tools

Buildah creates, as its name suggests, the functionality of Dockerfiles, which comprise the steps needed to build a container. Buildah imitates this functionality, but for containers in OCI format.

Skopeo is something like a container reload point: The tool helps to find container images and can tap into a variety of sources. In addition to Docker registries, other OCI registries and even local directories with images are supported.

Finally, Podman is a command-line tool that lets you control containers on your local system without the need for a control daemon, as is the case with Docker. This arrangement removes a vulnerable component from the equation and reduces administrative overhead.

If you look at the architecture of the container implementation in RHEL 8, you'll quickly realize that you have no need to concern yourself with Docker anymore. Docker itself said in a blog entry [4] as early as 2017 that it took a relaxed view of OCI – being one of its biggest contributors – and pointed out that OCI is only a container format, whereas Docker provides a complete collection of tools for creating and managing containers.

Exactly this objection has now been convincingly refuted by Red Hat in RHEL 8, and this move can be interpreted as an all-out attack on Docker. Additionally, RHEL 8 is likely to be the successor to most customers currently using RHEL 7, so the components described here will be found sooner or later to be integral parts on a huge number of systems. Docker's reaction to this critical circumstance might therefore be quite interesting to observe in the future.