In the next part of this article, we will go mostly through the better handling of software packages and more functional and safer support for containers and images. These elements are increasingly important in data centers and cloud environments.
Before we get to it, let’s start with the most interesting feature for bare metal servers and laptops, which is Boom Boot Manager.
Virtualization and the ability to use snapshots is invaluable. Everyone understands these benefits, and everyone uses them. From today we can also use them on bare metal and laptops. Along with RHEL8, the “boom” tool appeared. Boom Boot Manager uses LVM snapshot technology and Grub2 Boot Loader. The boom operation can be seen in this video and in this article.
If we want to use the benefits of a bare metal snapshots, it is very important to remember to leave enough free space for them.
Improved package and software support
The system is of little use without additional software, hence a lot has changed in this area. The method of obtaining software has been greatly simplified, mainly due to the use of modules and streams.
Modules are a new way of grouping packages that together form an application profile. One repository can support many such modules in parallel. Modules can contain multiple streams, providing the ability to install different versions of the same application. Stream represents a significantly different version of the same application. Most often, a new stream is created when the new version of the application is no longer backwards compatible. Only one application stream can be active within the module. Installing one application stream completely replaces the previous one, regardless of whether it is an upgrade or downgrade.
Therefore, we cannot have several versions of the same application within one user space, which was possible with RHSCL (Red Hat Software Collections). Fortunately, this is rarely needed nowadays due to the ubiquitous virtualization and containerization. The advantage of streams is that the application will always be installed in standard locations of the system catalog structure.
The modules completely replace RHSCL, allowing the operating system life cycle to be separated from the application life cycle. Modules are installed regardless of the operating system. This means that versions of operating system software packages do not affect module software and vice versa.
As a result, in RHEL8 we have only two main repositories, which should be sufficient for most use cases:
- BaseOS – packages required for a minimal installation of the operating system that form the userspace base on a selected hardware, virtual environment, cloud or container.
- AppStream – all the rest of the software packages used in the user space, except those that require additional subscriptions (add-on-ettitlements).
We also have a separate repository with proprietary software and for developers:
- Supplemental – just like in RHEL7, also includes licensed and proprietary software.
- CodeReady Linux Builder – packages typically used during code build. This is a repository dedicated to developers, whose elements should not be used in a production environment.
In addition, on September 24, 2019, the CentOS Stream distribution was launched. It contains versions of packages that will soon be released in the RHEL system. CentOS Stream is something between the Fedora and RHEL. The distribution was created for developers who create hardware and software solutions that are part of the Red Hat ecosystem. Thanks to this, they can prepare and adapt their products to new versions of RHEL system packages much earlier.
This completes the set of repositories for the RHEL8 system itself. All additions to the RHEL8 system, such as: High Availability, Resilient Storage, Real Time and Real Time for NFV also have their own separate repositories, to which we get access after purchasing the appropriate subscriptions. These are called add-on repositories.
The Extras and Optional repositories have been removed. Packages from them have been moved to AppStream or rejected. Rejected may in future appear in EPEL (Extra Packages for Enterprise Linux).
The use of modules and streams is a bit more complex, but well thought out and scalable. For example, within one stream, we can also have multiple profiles of the same application version with different configurations. Profiles are used to reflect different use cases of the same version of the application, thus giving the opportunity to provide files with different content with the application. If you don’t need the functions provided by modules, streams and profiles, you can use yum as if these functions were not there and you did it before.
RHEL8 uses yum version 4, which internally uses DNF technology. The recommended package management command is still yum, which is a symbolic link to the dnf command.
More functional and safer container and image handling
We say goodbye to Docker, and welcome to Podman, Buildah, Skopeo and Udica:
- Podman – engine for launching containers without daemon (daemonless).
- Buildah – building container images (from scratch or from Dockerfile).
- Skopeo – copying and inspection of container images in the Container Registries.
- Udica – utility for generating tailored SELinux policies for containers¹.
Podman uses the Fork/Exec model, so you can easily keep the real ID of the user who launched the container. It is located in /proc/self/loginuid. This information becomes useful when we use audit logs. When using Podman, the “auid=” parameter will always contain the ID of the user who started the container. This allows you to easily identify the source of unwanted activities.
Due to the fact that Docker works in the Client/Server model, the container is really a child of the Docker daemon, hence the information from audit logs about who created it is lost, and in the audit logs there is “auid=unset“. This is critical to safety. In this way, we lose information about where and by whom access to sensitive data from outside the container was obtained. Of course, if container security were broken first. What’s worse, we can never find out about the fact that our data is leaking through one of the containers. The reason for this is that the other parameters of audit logs, such as “uid=” and “gid=” may point to the root user ID.
Another problem in the area of security is the docker group and assigning users to it (giving permission to the docker socket). This is equivalent to giving administrative privileges to the entire operating system. This should not be done. If we have to, only trusted users should be added to this group. Does it have to be this way? Not necessarily. Using Podman and Buildah does not require root privileges to build and manage containers, nor does it belong to a special group. However, before migration, it is worth to paying attention to the differences in container startup procedure and in the area of network upon container launch from the root user level versus launch from the normal user level. User-created images are not visible to other ordinary users and are stored in their home directories. The lack of requirements for special permissions is certainly the reason why you should consider using Buildah in the CI/CD pipeline (Continuous Integration / Continuous Delivery). Thanks to Buildah, containers can be built interactively, using bash scripts or as we have done so far, by using the Dockerfile file.
Podman replaces the functions of the Docker commands well enough, that you can set an alias: “alias docker=’podman'”. So, the whole transition to Podman can be really painless and easy. However, it is worth paying attention to one thing. No docker-compose equivalent. In new versions, docker-compose focuses only on handling containers within a 1-host. In addition, Kubernetes YAML is the accepted standard for creating files describing pods. These two things are the reason why docker-compose equivalent is out of the Podman project scope. Podman itself can handle not only individual containers (like Docker itself), but also entire pods, consisting of many containers. If we want to describe the configuration of our Podman pods in a convenient and portable way, we should use Kubernetes YAML. For those who prefer docker-compose for some reason, a project called podman-compose² is being developed.
Of course, these are not all the differences and advantages of Podman, but only the reasons why we started migration from Docker to Podman in many places. Their number will probably increase over time, so it’s worth to follow this topic.
Together with the new containerization tools, Red Hat shared a UBI (Universal Base Image) image that allows anyone to create containers based on the RHEL system. As long as you can use it, Red Hat support will only be available if it is launched on the RHEL system or on the Red Hat OpenShift platform. More about UBI can be found on the Red Hat blog³.
As we are already at the images, it is worth mentioning the convenient possibility of creating personalized RHEL8 images. Currently, these output image formats are supported:
- QEMU QCOW2 Image (*.qcow2)
- Ext4 File System Image (*.img)
- Raw Partitioned Disk Image (*.img)
- Live Bootable ISO (*.iso)
- TAR Archive (*.tar)
- Amazon Machine Image (*.ami)
- Azure Disk Image (*.vhd)
- VMware Virtual Machine Disk (*.vmdk)
- OpenStack (*.qcow2)
This is possible thanks to Image Builder, whose interface is available from the CLI level and via Cockpit.
We hope that we have gently been able to bring closer what’s new is waiting for us in RHEL8.
We have certainly not described all the new functionalities of RHEL8, and with each subsequent release there will be more new functionalities and possibilities of using earlier ones. This is one of the values that the subscription gives us, which we often forget – the ability to use new features.
Therefore, for the reminder, as part of the subscription for Red Hat Enterprise Linux we receive:
- manufacturer support within the 10-year life cycle of the system,
- technical support 8/5 or 24/7,
- constant access to new versions of the software (security patches and new functionalities),
- access to the software source code (open source product)
- access to very good technical documentation, knowledge base built by Red Hat experts with many proven case studies,
- access to the Security Response Team (SRT), which produces recommendations after every emerging vulnerabilities (administrator immediately knows what steps to take),
- certification of product compliance, compliance with safety standards, and assurance of proper operation and compatibility with hardware, software and cloud services of many suppliers,
- access to Red Hat Insights, which analyzes the state of the system and its services and events occurring therein, and then correlates this information with the Red Hat Knowledge Base and best practices to provide recommendations that improve the performance, stability and security of the system and its services.
The purchase of such subscriptions also supports the Open Source community. Red Hat is one of the main sponsors not only of the Linux kernel, but also of many groups creating open source products. Thanks to this, they can be used for free where compliance with safety standards, certification of compliance between products, long life cycle and support, appropriate level of security, reliability, stability and high availability of the environment is not sufficiently business justified or we have a large and specialized IT department, that we can provide it ourselves and take responsibility for it.
The life cycle of the system and its support is very important. For most free systems it is up to 3 years. After a year, when the system becomes stable and can be implemented in production, it is only one year after which you need to start planning another renovation. For RHEL it is up to 10 years with the possibility to extend it (Red Hat Extended Life Cycle Support Add-On).
More about what’s new in RHEL8 available in:
- Why to choose Red Hat Enterprise Linux 8? – Part I,
- Safer DNS, e-mail and other improvements of RHEL 8 – Part II,
- Web-based management interface, sessions recording. RHEL 8 part III.