Introducing Application Streams in RHEL 8

With the introduction of Red Hat Enterprise Linux 8 (RHEL 8) we have tried to greatly simplify the layout of the content available in Red Hat Enterprise Linux. The main repository, BaseOS, provides the parts of the distribution that give you a running userspace on physical hardware, a virtual machine, a cloud instance or a container. The Application Stream (AppStream) repository provides all the applications you might want to run in a given userspace. The Supplemental repository provides other software that has special licensing. The CodeReady Linux Builder provides mostly build time components for developers (see Introducing CodeReady Linux Builder).

As a result, most RHEL 8 systems will only need two repositories enabled. However, this may lead to the the question, where do I find alternate versions of software if there is only 1 application repository? In prior versions, you would look to the RHSCL or Extras repositories. However, in RHEL 8, through a new technology called Modularity, we can offer those alternate versions in the same physical repository.

Continue reading “Introducing Application Streams in RHEL 8”

Share

Red Hat Enterprise Linux 8 Beta is here!

Red Hat Enterprise Linux 8 Beta is here!

And it’s been built with production stability and development agility in mind.

There’s so much to say about RHEL 8 Beta, but I want to focus on just a few points from the corporate announcement that highlight Red Hat Enterprise Linux 8 Beta as a developer platform that:

  • Simplifies application development – with less setup and config effort, you can more quickly get to writing code
  • Is the easiest RHEL yet for developers that are new to Linux
  • Is for traditional and cloud/container applications with many new tools for both
  • Already delivers dozens of tools to build and test applications

Now let’s zoom in on what these mean.

“Too slow, too fast”

We’ve gotten this feedback a lot when discussing availability and support of development packages. To address this dichotomy, Red Hat Enterprise Linux 8 Beta has built in the concept of Application Streams to deliver userspace packages (programming languages, compilers, databases, etc.) more simply and with greater flexibility – this addresses the “too slow”.  For the “too fast” requirement, there are also “Core” components that have the same lifecycle as the operating system – 10 years. Users will often have a version in each grouping. Application Streams – think of them as “son of Software Collections” – are a simpler way to deliver this modularity with improved installation, use, and re-use

Continue reading “Red Hat Enterprise Linux 8 Beta is here!”

Share

PHP 7.2, Node.js 10, NGINX 1.14 and others now GA for RHEL

We are pleased to announce general availability Red Hat Software Collections 3.2, which adds these components to Red Hat Enterprise Linux 7:

  • PHP 7.2
  • Varnish Cache 6.0
  • MySQL 8.0
  • NGINX 1.14
  • Node.js 10
  • Git 2.18
  • Update of Apache HTTP server 2.4

These versions are available on Red Hat Enterprise Linux 7 (Devtools or RHSCL channel) for x86_64, s390x, aarch64, and ppc64le.  Read more details about each component in the “New Components details” section.

Continue reading “PHP 7.2, Node.js 10, NGINX 1.14 and others now GA for RHEL”

Share

GCC 8.2 now GA for Red Hat Enterprise Linux

We are pleased to announce general availability of Red Hat Developer Toolset 8 for Red Hat Enterprise Linux 6 and 7.  The key new components for this release are:

  • GCC 8.2.1
  • GDB 8.2
  • Updated components such as SystemTap, Valgrind, OProfile, and many more

Like other tools, these are installable via yum from the Red Hat Enterprise Linux 6 or 7 Devtools or RHSCL channel.  For more details, see the “New Features” section below.

Continue reading “GCC 8.2 now GA for Red Hat Enterprise Linux”

Share

Why you should care about RISC-V

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.

But why should you care? You can’t just go to the local electronics boutique and buy a RISC-V laptop or blade server. RISC-V commodity hardware is either scarce or expensive. It’s all still early in its lifespan and development, not yet ready for enterprise tasks. Yet it’s still something that the average professional should be aware of, for a number of reasons.

By now everyone has heard about the Meltdown and Spectre issues, and related “bugs” users have been finding in Intel and AMD processors. This blog is not about how hard CPU design is – it’s hard. Even harder than you realize. The fear created by these bugs was not that there was a problem in the design, but that users of these chips had no insight into how these “black boxes” worked, no way to review code that was outside their control, and no way to audit these processors for other security issues. We’re at the mercy of the manufacturer to assure us there are no more bugs left (ha!).

The advantage of an open core here is that a company can audit the internal workings of a processor, at least in theory. If a bug is found by one chip manufacturer using a RISC-V core, the fix can be shared with other manufacturers. And certainly, if there are bugs to be exploited, the black hats and white hats will be able to find them (and fix them) much faster and sooner.

And what if you do want to try a RISC-V system today? Support for 64-bit RISC-V cores with common extensions (MAFD – multiply/divide, atomics, float, and double – aka the ‘G’ set) was added to the GNU C Library (glibc) in version 2.27, which means (for example) Fedora 28 contains RISC-V support. Bootable images are available, which run in a qemu emulator (standard in Fedora) or on real hardware (such as the SiFive HiFive Unleashed board).

A team of volunteers (of which I am one) is currently working on building the latest Fedora packages for RISC-V on a large number of emulators and a small number of hardware systems, such as this one (mine):

HiFive1 Board

An early access RISC-V development system. Upper right is the HiFive board. Bottom is a VC707 board which provides a PCIe bridge. Middle left is a PCIe riser board. At the top is a commodity PCIe SSD card. Connections on the right: USB serial console, ethernet, power. Additional mess is optional, and at the discretion of the desk owner.

But are there down sides to choosing an open core? Well, there are considerations that anyone should be aware of when choosing any core. Here are a few:

  • More flexibility for you. If you need to integrate a core into a custom ASIC for your hardware, with custom peripherals, an open core gives you a good base core to work from. However…
  • More work for you. A core is just a core, you need to add everything (serial ports, DDR interfaces) yourself.
  • A wider range of options and configurations. You get to decide which extensions and peripherals your core will have, which minimizes space and cost of each implementation. However…
  • A fragmented ecosystem is possible. If you customize your core too much, you might need to customize the tools to match, and sharing code and designs becomes more complicated. Distributions like Fedora standardize on a set of common extensions that manufacturers can include to ensure compatibility.
  • An open design means anyone can audit the design for security. However…
  • An open design means everyone must audit the design for security. Perhaps an ecosystem for audits and auditing will arise.
  • An open design can be cheaper on a per-core basis, due to the lack of licensing costs and freely available tooling. However…
  • An open design can be more expensive due to the lack of a robust ecosystem to drive engineering costs down.

So, like all things engineering… YMMV.

In summary… any time something new comes around, in this case a new processor core and a new way of thinking about the intellectual property therein, it offers users more choices about where they want to put their efforts, resources, and risks. For me, having (and supporting) a new architecture give me an opportunity to hone my skills as well as revisit old decisions about how platforms can be used portably.

Resources

Share

Migrating from Oracle JDK to OpenJDK on Red Hat Enterprise Linux: What you need to know

Oracle has announced that the Oracle JDK 8 builds released after Jan 2019 cease to be free for commercial use. GPL + Classpath Exception licensed (free for any use, subject to that license) are current made available by Oracle through http://jdk.java.net/11/. (See also Oracle’s blog entry & licensing).
An alternative is to use OpenJDK and effort is underway to make them fully interchangeable. A number of companies who are currently using Oracle JDK in production are making the decision to switch to OpenJDK or have already done so.

Andrew Haley (Red Hat’s Java Platform Lead Engineer) recently wrote a great article on the direction of OpenJDK.

In this article, I’ll discuss: the technical and support implications of the migration, what developers and operations teams need to know, and solutions to potential challenges.

I’ll go over the Red Hat support model and technical details of how to install, update, and run different OpenJDK versions on Red Hat Enterprise Linux (RHEL) 6 and 7 systems. I’ll also discuss the operations of Java applications (such as Red Hat JBoss Enterprise Application Platform (JBoss EAP) and other servers) on top of OpenJDK.

While this article is about OpenJDK on RHEL, I should also point out that OpenJDK for Windows can also be downloaded from developers.redhat.com. This lets you use the same JDK for Linux and Windows.

Continue reading “Migrating from Oracle JDK to OpenJDK on Red Hat Enterprise Linux: What you need to know”

Share

How to manually copy SSH public keys to servers on Red Hat Enterprise Linux

We often use ssh-copy-id to copy ssh keys from our local Linux computers to RHEL servers in order to connect without typing in a password. This is not only for convenience; it enables you to script and automate tasks that involve remote machines.  Also, using ssh keys correctly is considered a best practice.  If you are conditioned to respond with your password every time you are prompted, you might not notice a prompt that isn’t legitimate (for example, spoofed).

What about when you can’t use ssh-copy-id or the target user ID doesn’t have a password (for example, an Ansible service user)? This article explains how to do it manually and avoid the common pitfall of forgetting to set the proper permissions.

Continue reading “How to manually copy SSH public keys to servers on Red Hat Enterprise Linux”

Share

GCC 8 and tools now in beta for Red Hat Enterprise Linux 6 and 7

We are pleased to announce the immediate availability of Red Hat Developer Toolset 8 beta for Red Hat Enterprise Linux 6 and 7.  The key new components for this release are:

  • GCC 8.2.1
  • GDB 8.2
  • Updated components such as SystemTap, Valgrind, OProfile, and many more

Like other tools, these are installable via yum from the Red Hat Enterprise Linux 6 or 7 Devtools or RHSCL channel.  For more details, see the “New Features” section below.

Continue reading “GCC 8 and tools now in beta for Red Hat Enterprise Linux 6 and 7”

Share

Newest PHP, Varnish Cache, MySQL, NGINX, Node.js, and Git now in beta

We are pleased to announce the immediate availability Red Hat Software Collections 3.2 beta, which adds these components to Red Hat Enterprise Linux 7:

  • PHP 7.2
  • Varnish Cache 6.0
  • MySQL 8.0
  • NGINX 1.14
  • Node.js 10
  • Git 2.18
  • Update of Apache HTTP server 2.4

These beta versions are available on Red Hat Enterprise Linux 7 (Devtools or RHSCL channel) for x86_64, s390x, aarch64, and ppc64le.  Read more details about each component in the “New Components details” section.

Continue reading “Newest PHP, Varnish Cache, MySQL, NGINX, Node.js, and Git now in beta”

Share

Introduction to Linux interfaces for virtual networking

Linux has rich virtual networking capabilities that are used as basis for hosting VMs and containers, as well as cloud environments. In this post, I will give a brief introduction to all commonly used virtual network interface types. There is no code analysis, only a brief introduction to the interfaces and their usage on Linux. Anyone with a network background might be interested in this blog post. A list of interfaces can be obtained using the command ip link help.

This post covers the following frequently used interfaces and some interfaces that can be easily confused with one another:

After reading this article, you will know what these interfaces are, what’s the difference between them, when to use them, and how to create them.

Continue reading “Introduction to Linux interfaces for virtual networking”

Share