An Abridged Guide to the Enterprise Linux Landscape

An Abridged Guide to the Enterprise Linux Landscape

Whether you are welcoming CentOS Stream or looking for alternatives, the recent decision from the CentOS community to focus on CentOS Stream has forced a lot of technical leaders to rethink their Enterprise Linux strategy.  Beneath that decision, the business landscape involving Linux has shifted and expanded since its enterprise debut in the late 90s, when IBM would invest $1 billion in its development.

Today, Linux comes in every shape and size imaginable — with the kernel running on tiny low power computers and IoT devices, mobile phones, tablets, laptops all the way up to midrange and high-power mainframe servers.

Cutting through that expansive selection to understand which Linux distributions truly align with the needs of a business can lead to more frictionless deployments and successful execution while minimizing waste in maintenance cycles and optimizing overall cost.

This abridged guide to the Enterprise Linux landscape can give businesses an overview of which flavor (or flavors) of Linux will most adequately match their use cases.

For those looking for a more comprehensive guide, be sure to check out the Decision Maker’s Guide to Enterprise Linux.

Finding the Right Linux Flavor

Committing to a flavor can introduce many concerns. Beyond managing the deployments host-by-host, administrators must also consider the ecosystem components available to support the implementation at scale.

What mechanisms will be available for automatic patching? Can you optimize bandwidth by mirroring the distributions repository? Is remote desktop a concern?  What about the kernel version requirements? Linux Kernel 4 contains optimizations that lead directly to dollars saved on cloud deployments, can you take advantage of that?TUX

Are you looking at a container strategy, thinking of deploying your apps into Kubernetes, or other multi-cloud strategies? What about options for embedded Linux

Nowadays there’s a preferred flavor of Linux for each of these concerns. A single flavor of Linux is really the Linux kernel surrounded by a curated suite of other free software. That other free software is what makes one flavor of Linux distinct from another.

Systemd Service Strengthening

Systemd Service Strengthening


In an age where hacker attacks are a daily occurrence, it is of fundamental importance to minimize the attack surface. Containerization is probably the best way to isolate a service provided for the public, but this is not always possible for several reasons. For example, think of a legacy system application developed on systemd. This could make the most of the capabilities provided by a systemd-based operative system and it could be managed via a systemd unit, or it could automatically pull updates using a systemd timer, and so on.

For this reason, we are going to explain how to improve the security of a systemd service. But first, we need to step back for a moment.  With the latest releases systemd has implemented some interesting features relating to security, especially sandboxing. In this article we are going to show step-by-step how to strengthen services using specific directives, and how to check them with the provided systemd suite.


Systemd provided an interesting tool named systemd-analyze. This command analyzes the security and the sandboxing settings of one or more specified services. The command checks for various security-related service settings, assigning each a numeric "exposure level" value, depending on how important the setting is. It then calculates an overall exposure level for the whole unit through an estimation in the range 0.0…10.0, which tells us how exposed a service is security-wise.

Systemd Analyze


This allows us to check the improvements applied to our systemd service step-by-step. As you can see, several services are now marked as UNSAFE, this is probably due to the fact that not all of the applications are applying the features provided by systemd.

Getting Started

Let's start from a basic example. We want to create a systemd unit to start the command python3 -m http.server as a service:

Description=Simple Http Server

ExecStart=/usr/bin/python3 -m http.server
ExecStop=/bin/kill -9 $MAINPID


Save the file and place it under the specific systemd directory of yor distribution.

By checking the security exposure through systemd-analyze security we get the following result:

eBPF for Advanced Linux Infrastructure Monitoring

eBPF for Advanced Linux Infrastructure Monitoring

A year has passed since the pandemic left us spending the better part of our days sheltering inside our homes. It has been a challenging time for developers, Sysadmins, and entire IT teams for that matter who began to juggle the task of monitoring and troubleshooting an influx of data within their systems and infrastructures as the world was forced online. To do their job properly, free, open-source technologies like Linux have become increasingly attractive, especially amongst Ops professionals and Sysadmins in charge of maintaining growing and complex environments. Engineers, as well, are using more open-source technologies largely due to the flexibility and openness they have to offer, versus commercial offerings that are accompanied by high-cost pricing and stringent feature lock-ins.

One emerging technology in particular - eBPF - has made its appearance in multiple projects, including commercial and open-source offerings. Before discussing more about the community surrounding eBPF and its growth during the pandemic, it’s important to understand what it is and how it’s being utilized. eBPF, or extended Berkley packet filtering, was originally introduced as BPF back in 1992 in a paper by Lawrence Berkeley Laboratory researchers as a rule-based mechanism to filter and capture network packets. Filters would be implemented to run inside a register-based Virtual Machine (VM), which itself would exist inside the Linux Kernel. After several years of non-activity, BPF was extended to eBPF, featuring a full-blown VM to run small programs inside the Linux Kernel. Since these programs run from inside the Kernel, they can be attached to a particular code path and be executed when it is traversed, making them perfect to create applications for packet filtering and performance analysis and monitoring.

Originally, it was not easy to create eBPF programs, as the programmer needed to know an extremely low-level language. However, the community around that technology has evolved considerably through their creation of tools and libraries to simplify and speed up the process of developing and loading an eBPF program inside the Kernel. This was crucial for creating a large number of tools that can trace system and application activity down to a very granular level. The image that follows demonstrates this, showing the sheer number of tools that exist to trace various parts of the Linux stack.