Several months ago, I took over the maintenance of the flex package in Fedora and decided to kick the tires by rebasing the package in Fedora Rawhide. I downloaded and hashed the latest tarball at the time, flex-2.6.4, tweaked the spec file, and fired up a local build. Unfortunately, it failed with a
SIGSEGV at build time:
./stage1flex -o stage1scan.c ./scan.l
make: *** [Makefile:1695: stage1scan.c] Segmentation fault (core dumped)
Some debugging with gdb led me to the conclusion that the segmentation fault was the result of a block of memory returned from the
reallocarray function being written to during flex initialization. In this article, I’ll describe the issue further and explain changes made to address it.
Continue reading “Implicit function declarations: flex’s use of “reallocarray””
Application developers continue to need newer versions of libraries, including core runtimes like GNU C Library (glibc), for their applications. In this article, I’ll look at some issues related to upgrading glibc in an operating system (OS) distribution, and I also encourage you to read Florian Weimer’s excellent blog post on the topic.
Deciding between a library rebase or continued backporting of commits involves a complex set of risks and rewards. For some customers and users, it is important not to rebase the library (ensuring the lowest risk of impact by change); but for others, the rebase brings valuable bug fixes (lowest risk of impact from known issues). In other cases, the newer library may perform better, even if the interfaces haven’t changed, because it can take advantage of newer hardware or a newer Linux kernel (performance advantage to first mover).
There is no way to simultaneously satisfy all the requirements of slow-moving versus fast-moving development. The recent work in Fedora Modularity is aimed at solving the root of this problem, but there is a limit to this work. The further down the stack you go, the harder the problem becomes. The potential for breakage further up the stack increases. You can’t always arbitrarily change a component’s installed version without consequences, either at build time or at runtime.
Continue reading “A platform interface for the GNU C Library”
I work at Red Hat on GCC, the GNU Compiler Collection, and I spent most of the past year making GCC easier to use. Let’s look at C and C++ improvements that will be in the next major release of GCC, GCC 9.
Continue reading “Usability improvements in GCC 9”
I was asked recently on Twitter to better explain Podman and Buildah for someone familiar with Docker. Though there are many blogs and tutorials out there, which I will list later, we in the community have not centralized an explanation of how Docker users move from Docker to Podman and Buildah. Also what role does Buildah play? Is Podman deficient in some way that we need both Podman and Buildah to replace Docker?
This article answers those questions and shows how to migrate to Podman.
Continue reading “Podman and Buildah for Docker users”
In the first part of this series, we saw how effective a platform as a service (PaaS) such as Red Hat OpenShift is for developing IoT edge applications and distributing them to remote sites, thanks to containers and Red Hat Ansible Automation technologies.
Usually, we think about IoT applications as something specially designed for low power devices with limited capabilities. IoT devices might use a different CPU architectures or platform. For this reason, we tend to use completely different technologies for IoT application development than for services that run in a data center.
In part two, we explore some techniques that allow you to build and test contains for alternate architectures such as ARM64 on an x86_64 host. The goal we are working towards is to enable you to use the same language, framework, and development tools for code that runs in your datacenter or all the way out to IoT edge devices. In this article, I’ll show building and running an AArch64 container image on an x86_64 host and then building an RPI3 image to run it on physical hardware using Fedora and Podman.
Continue reading “IoT edge development and deployment with containers through OpenShift: Part 2”
The Annobin plugin for GCC stores extra information inside binary files as they are compiled. Examining this information used to be performed by a set of shell scripts, but that has now changed and a new program—annocheck—has been written to do the job. The advantage of the program is that it is faster and more flexible than the scripts, and it does not rely upon other utilities to actually peer inside the binaries.
This article is about the annocheck program: how to use it, how it works, and how to extend it. The program’s main purpose is to examine how a binary was built and to check that it has all of the appropriate security hardening features enabled. But that is not its only use. It also has several other modes that perform different kinds of examination of binary files.
Another feature of annocheck is that it was designed to be easily extensible. It provides a framework for dissecting binary files and a set of utilities to help with this examination. It also knows how to handle archives, RPMs, and directories, presenting the contents of these to each tool as a series of ordinary files. Thus, tools need only worry about the specific tasks they want to carry out.
Continue reading “Annocheck: Examining the contents of binary files”
In this article, I discuss containers, but look at them from another angle. We usually refer to containers as the best technology for developing new cloud-native applications and orchestrating them with something like Kubernetes. Looking back at the origins of containers, we’ve mostly forgotten that containers were born for simplifying application distribution on standalone systems.
In this article, we’ll talk about the use of containers as the perfect medium for installing applications and services on a Red Hat Enterprise Linux (RHEL) system. Using containers doesn’t have to be complicated, I’ll show how to run MariaDB, Apache HTTPD, and WordPress in containers, while managing those containers like any other service, through systemd and
Additionally, we’ll explore Podman, which Red Hat has developed jointly with the Fedora community. If you don’t know what Podman is yet, see my previous article, Intro to Podman (Red Hat Enterprise Linux 7.6) and Tom Sweeney’s Containers without daemons: Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta.
Continue reading “Managing containerized system services with Podman”
In most glibc-based operating systems, there’s a file /etc/nsswitch.conf that most people ignore, few people understand, but all people generally rely on. This file determines where the system finds things like host names, passwords, and protocol numbers. Does your company use LDAP? NIS? Plain files? The nsswitch file (it stands for “name services switch”) tells the system what service to use for each type of name lookup.
Continue reading The Non-complexity of /etc/nsswitch.conf
If you haven’t heard about the RISC-V (pronounced “risk five”) processor, it’s an open-source (open-hardware, open-design) processor core created by the University of Berkeley. It exists in 32-bit, 64-bit, and 128-bit variants, although only 32- and 64-bit designs exist in practice. The news is full of stories about major hardware manufacturers (Western Digital, NVidia) looking at or choosing RISC-V cores for their product.
Continue reading Why you should care about RISC-V
A number of the SystemTap script examples in the newly released SystemTap 4.0 available in Fedora 28 and 29 have reduced the amount of time required to convert the scripts into running instrumentation by using the
This article discusses the particular changes made in the scripts and how you might also use this new tapset to make the instrumentation that monitors system calls smaller and more efficient. (This article is a follow-on to my previous article: Analyzing and reducing SystemTap’s startup cost for scripts.)
The key observation that triggered the creation of the
syscall_any tapset was a number of scripts that did not use the
syscall arguments. The scripts often used
syscall.*.return, but they were only concerned with the particular
syscall name and the return value. This type of information for all the system calls is available from the
sys_exit kernel tracepoints. Thus, rather than creating hundreds of kprobes for each of the individual functions implementing the various system calls, there are just a couple of tracepoints being used in their place.
Continue reading “Reducing the startup overhead of SystemTap monitoring scripts with syscall_any tapset”