Ever since Red Hat announced that they are changing the development model of CentOS and making it an upstream project rather than downstream, it left many CentOS users frowning. No matter what argument brought forward, CentOS users, especially running production machines, relied on the stability of an enterprise-grade Linux distribution. Compiled from RHEL sources, CentOS offered such stability that it powered many web servers and enjoyed a massive 20% share of the top 500 supercomputers of the world.

• Cloud Native Patterns: a free ebook for developers

  Building cloud native applications is a challenging undertaking, especially considering the rapid evolution of cloud native computing. But it’s also very liberating and rewarding. You can develop new patterns and practices where the limitations of hardware dependent models, geography, and size no longer exist. This approach to technology can make cloud application developers more agile and efficient, even as it reduces deployment costs and increases independence from cloud service providers.

  Oracle is one of the few cloud vendors to also have a long history of providing enterprise software. Wearing both software developer and cloud service provider hats, we understand the complexity of transforming on-premises applications into cloud native applications. Removing that complexity for customers is a guiding tenet at Oracle.

• Red Hat extends certification expiration dates and expands remote offerings

  In 2020, remote exams became the standard experience for certificate-hopefuls across many fields. Red Hat worked quickly to release four of our most in-demand exams in this format. We have seen remote exams grow rapidly in popularity with our candidates. As we roll into 2021, our list has expanded with even more offerings. Now, you can take advantage of more remote exams to validate your skills in Red Hat’s most in-demand technologies, including OpenShift, Ansible, Containers and Kubernetes, and more.

• CloudLinux Expands Its Extended Lifecycle Support Services to Cover More End-of-Life Linux Distributions

• CloudLinux to Offer Lifecycle Support Services for Expired Linux Distributions

  CloudLinux on Monday announced the expansion of its affordable Extended Lifecycle Support (ELS) services for Linux distributions, by providing its own updates and security patches for several years after expiration of the products’ end-of-life date.

Five weeks after angering much of the CentOS Linux developer community by unveiling controversial changes to the no-cost CentOS operating system, Red Hat has unveiled alternatives for affected users that give them several options for using existing Red Hat products.

But for many users of CentOS Linux, the Red Hat options won’t solve the huge problems that were created for them when Red Hat announced Dec. 8 that CentOS would no longer include a stable version with a long, steady future. Instead, CentOS will now only be offered as a free CentOS Stream operating system which will be a rolling release with frequent updates, essentially turning it into a beta OS that is no longer suitable for reliable production workloads. For users who have deployed CentOS throughout the internet, data centers, corporate and business uses and more, this is a potentially major blow.

Also: Fedora program update: 2021-03

• A possible step toward integrity measurement for Fedora

  The Fedora 34 release is planned for April 20 — a plan that may well come to fruition, given that the Fedora project appears to have abandoned its tradition of delayed releases. As part of that schedule, any proposals for system-wide changes were supposed to be posted by December 29. That has not stopped the arrival of a late proposal to add file signatures to Fedora's RPM packages, though. This proposal, meant to support the use of the integrity measurement architecture (IMA) in Fedora, has not been met with universal acclaim.
  The purpose of IMA is to measure whether the integrity of the system is intact, where "integrity" means that the important files in the system have not been corrupted. At its core, this measurement is carried out by reading a file's contents, computing a hash, and comparing that hash to the expected value; if the values match, the file has not been altered. This measurement can be used to prevent the execution (or reading) of corrupted files; it can also be used as part of a remote attestation scheme to convince a remote party that the local system has not been subjected to unauthorized modifications.

  To perform this measurement, IMA clearly must know what the expected hash for each file is; those hashes are signed with a key trusted by the kernel and stored as extended attributes. Generally, the private key used to sign these hashes is kept in some secure location, while the public key is either stored in a device like a trusted platform module (TPM) or built into the kernel binary. If all works as intended, IMA can thus be used to ensure that systems only run executables that have been blessed by some central authority, that those executables only read configuration files that have been similarly blessed, and so on. It is a mechanism for ensuring that the owner of a system keeps control of it; whether this is a good thing or not depends entirely on who the "owner" is defined to be.

  The actual proposal does not go so far as to implement IMA on Fedora systems; it is limited to including signatures with every file that is shipped in Fedora packages. These signatures "will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults". Fedora users would then be able to use IMA to keep their systems from using files that have been modified since they were packaged. An actual IMA setup for Fedora can be expected to come at some future time.

• Fedora Loves Python 2020 report – Fedora Community Blog

  Inspired by a similar report from the Copr team, I’ve decided to look back at 2020 from the perspective of Python in Fedora (and little bit in RHEL/CentOS+EPEL as well). Here are the things we have done in Fedora (and EL) in 2020. By we I usually mean the Python Maint team at Red Hat and/or the Fedora’s Python SIG.

• Introducing the Red Hat build of Eclipse Vert.x 4.0 - Red Hat Developer

  If you are interested in reactive, non-blocking, and asynchronous Java development, you are likely familiar with Eclipse Vert.x. The project started in 2011 and successfully moved to the Eclipse Foundation in 2013. Since then, Vert.x has undergone nine years of rigorous development and grown into a thriving community. It is one of the most widely used reactive frameworks, with support for multiple extensions, including extensions for messaging or streaming with Kafka or Artemis, developing applications with gRPC and GraphQL, and so much more.

  The Red Hat build of Eclipse Vert.x 4.0 is now generally available. This release improves Vert.x’s core APIs and handling. Developers who migrate can expect enhancements to futures and promises, distributed tracing, and deployment on Red Hat OpenShift. In this article, I introduce these updates and offer tips for migrating and deploying your Eclipse Vert.x 4.0 applications on OpenShift.

• Implementing the ACSC "Essential Eight" baseline for security automation in Red Hat Enterprise Linux

  Achieving compliance with a security policy and maintaining compliance can be tedious. At Red Hat, we believe that such things should be automated and not become an unnecessary burden. To this end, we offer a whole ecosystem of services that automate security compliance.

  We ship several widely used security policies with our products. Today, we will go over the "Essential Eight" baseline in a bit more detail.

  The "Essential Eight" is a set of mitigation strategies created by the Australian Cyber Security Centre (ACSC), part of the Australian Signals Directorate (ASD) that leads the Australian Government’s efforts to improve cybersecurity.

• Painless services: implementing serverless with rootless Podman and systemd

  Serverless is an event-driven computing paradigm where applications are allocated dynamically to serve a request or consume events. When the application is not in use, there are no computing resources allocated.

  The serverless ecosystem offers a large number of runtimes, which start/stop/monitor software (e.g., Knative, Kubeless and many others). They come with different features, and they can trigger applications based on different kind of events (e.g., HTTP requests, messages, etc.).

  Even if systemd cannot be considered a real serverless runtime, the socket activation feature provides a foundation for a serverless architecture.

• Convert your Windows install into a VM on Linux | Opensource.com

  I use VirtualBox frequently to create virtual machines for testing new versions of Fedora, new application programs, and lots of administrative tools like Ansible. I have even used VirtualBox to test the creation of a Windows guest host.

  Never have I ever used Windows as my primary operating system on any of my personal computers or even in a VM to perform some obscure task that cannot be done with Linux. I do, however, volunteer for an organization that uses one financial program that requires Windows. This program runs on the office manager's computer on Windows 10 Pro, which came preinstalled.

  This financial application is not special, and a better Linux program could easily replace it, but I've found that many accountants and treasurers are extremely reluctant to make changes, so I've not yet been able to convince those in our organization to migrate.

• Red Hat's StackRox Acquisition Bolsters Its Hybrid Multi-Cloud Strategy

  The startup has container security capabilities that are missing in Red Hat's OpenShift Kubernetes platform.

  [...]

  "We are working on looking at a few things, and that will have to be run through them because they're the bank now," he said. "They're a partner, but they're also our shareholders."

  It's doubtful that Red Hat would have to go to the IBM bank to finance this purchase. Although no details of the deal were made public, most media reports are putting the price tag at just north of $100 million, far less than the $250 million it paid for CoreOS in 2018.

  As to be expected from Red Hat, which has traditionally insisted that all of its software be open source, Red Hat plans to open source StackRox’s proprietary software after the acquisition closes sometime in the first quarter of 2021. Red Hat said it will continue to support the existing KubeLinter open source community, as well as the new communities that form around StackRox’s other offerings as soon as they are open sourced.