You’ve probably seen tutorials that use
sudo for running administrative commands as root. However when you try it, you get told your user ID is “not in the sudoers file, this incident will be reported.” For developers,
sudo can be very useful for running steps that require root access in build scripts.
This article covers:
- How to configure
sudo access on Red Hat Enterprise Linux (RHEL) so you won’t need to use
su and keep entering the root password
sudo to not ask for your password
- How to enable
sudo during system installation
sudo seems to work out of the box for some users and not others
Continue reading “How to enable sudo on RHEL”
Rsync is a particularly tough workload for GlusterFS because with its defaults, it exercises some of the worst case operations for GlusterFS. GlusterFS is the core of Red Hat Gluster’s scale-out storage solution. Gluster is an open, software-defined storage (SDS) platform that is designed to scale out to handle data intensive tasks across many servers in physical, virtual, or cloud deployments. Since GlusterFS is a POSIX compatible distributed file system, getting the best performance from rsync requires some tuning/tweaking on both sides.
In this post, I will go through some of the pain points and the different tunables for working around the pain points. Getting rsync to run as fast on GlusterFS as it would on a local file system is not really feasible given its architecture, but below I describe how to get as close as possible.
Continue reading “Improving rsync performance with GlusterFS”
This article shows how to install Python 3,
pipenv on Red Hat Enterprise Linux 7. After following the steps in this article, you should be in a good position to follow many Python guides and tutorials using RHEL.
Using Python virtual environments is a best practice to isolate project-specific dependencies and create reproducible environments. Other tips and FAQs for working with Python and software collections on RHEL 7 are also covered.
There are a number of different ways to get Python 3 installed on RHEL. This article uses Red Hat Software Collections because these give you a current Python installation that is built and supported by Red Hat. During development, support might not seem that important to you. However, support is important to those who have to deploy and operate the applications you write. To understand why this is important, consider what happens when your application is in production and a critical security vulnerability in a core library (for example SSL/TLS) is discovered. This type of scenario is why many enterprises use Red Hat.
Python 3.6 is used in this article. It was the most recent, stable release when this was written. However, you should be able to use these instructions for any of the versions of Python in Red Hat Software Collections including 2.7, 3.4, 3.5, and future collections such as 3.7.
Continue reading “How to install Python 3 on RHEL”
Firewalld, the default firewall management tool in Red Hat Enterprise Linux and Fedora, has gained long sought support for nftables. This was announced in detail on firewalld’s project blog. The feature landed in the firewalld 0.6.0 release as the new default firewall backend.
The benefits of nftables have been outlined on the Red Hat Developer Blog:
There are many longstanding issues with firewalld that we can address with nftables that were not possible with the old iptables backend. The nftables backend allows the following improvements:
Continue reading “Firewalld: The Future is nftables”
Earlier this year, Red Hat announced the Red Hat Cache Service which is a distributed in-memory caching service that runs on Red Hat OpenShift. Red Hat Data Grid is used as the core of the cache service. The cache service is one of the things you can easily install on OpenShift through the OpenShift Service Catalog. You can find the cache service in the Red Hat OpenShift Online Pro tier. (Alternatively, you can install the Cache Service on your own Red Hat OpenShift Container Platform installation by following the installation manual.)
The Cache Service automatically calculates the amount of user storage based on the container size it’s scheduled on. Typically, it’s 512MB. What’s more interesting is that the Cache Service can operate near the full memory capacity (~97–98 %).
The automatic memory adjustment gives you a nice opportunity to try out the new Horizontal Pod Autoscaler (which now supports memory and custom metrics-based autoscaling). The autoscaler monitors the amount of memory used by the container and adds or removes Cache Service pods based on this measurement.
Continue reading “Autoscaling the Red Hat Cache Service on OpenShift”
One thing that is common in the enterprise world, especially in highly regulated industries, is to have separation of duties. Role-based access controls (RBAC) have built-in support for separation of duties. Roles determine what operations a user can and cannot perform. This post provides an example of how to configure proper RBAC on top of Red Hat AMQ, a flexible, high-performance messaging platform based on the open source Apache ActiveMQ Artemis project.
In most of the cases, separation of duties on Red Hat AMQ can be divided into three primary roles:
- Administrator role, which will have all permissions
- Application role, which will have permission to publish, consume, or produce messages to a specific address, subscribe to topics or queues, or create and delete addresses.
- Operation role, which will have read-only permission via the web console or supported protocols
To implement those roles, Red Hat AMQ has several security features that need be configured, as described in the following sections.
Continue reading “Setting up RBAC on Red Hat AMQ Broker”
[We are reposting on the Red Hat Developers blog this article from the Red Hat OpenShift blog, which was written by Diane Mueller-Klingspor.]
When we released OpenShift Origin as the open source upstream project for Red Hat OpenShift back in April 2012, we had little inkling of the phenomenal trajectory of cloud-native technology that was to come. With all the work that has gone into the Kubernetes-based core platform (OpenShift 3) from the initial OpenShift Origin 1.0 Release (OpenShift 3) in June 2015, to the current release of Red Hat OpenShift 3.10 release last week, we’ve seen the rise of Kubernetes and containers create the basis of the cloud-native landscape. We collaborated in the incubation and maturation of dozens of new cloud-native projects and into a myriad of upstream projects, expanding the universe of tools and platforms in a way we could only have dreamed about just three years ago.
So it’s time for a new logo, a new website, and a new name for our open source project. We are changing the name of our open source project to better represent who we are today, and who we’ll be tomorrow—the Origin community distribution of Kubernetes that powers Red Hat OpenShift.
Continue reading “OKD: Renaming of OpenShift Origin with 3.10 release”
Integration testing is still an important step in a CI/CD pipeline even when you are developing container-native applications. Integration tests tend to be very resource-intensive workloads that run for a limited time.
I wanted to explore how integration testing technologies and tools could leverage a container orchestrator (such as Red Hat OpenShift) to run faster and more-dynamic tests, while at the same time using resources more effectively.
In this post, you will learn how to build behavior-driven development (BDD) integration tests using Cucumber, Protractor, and Selenium and how to run them in OpenShift using Zalenium.
The code for the example of this article can be found on GitHub in redhat-cop/container-pipelinesh.
Continue reading “Container-native integration testing”
Microservices and serverless architectures are being implemented, or are a part of the roadmap, in most modern solution stacks. Given that Java is still the dominant language for business applications, the need for reducing the startup time for Java is becoming more important. Serverless architectures are one such area that needs faster startup times, and applications hosted on container platforms such as Red Hat Openshift can benefit from both fast Java startup time and a smaller Docker image size.
Let’s see how GraalVM can be beneficial for Java-based programs in terms of speed and size improvements. Surely, these gains are not bound to containers or serverless architectures and can be applied to a variety of use cases.
Continue reading “Natively compile Java code for better startup time”
[We are reposting on the Red Hat Developers blog this article from the Red Hat blog, which was written by David Levine, assistant general counsel at Red Hat.]
“Discourage litigation. Persuade your neighbors to compromise whenever you can.”
This was Abraham Lincoln speaking in the mid-1800s but his advice is still relevant today. Litigation is almost always a poor tool for fostering collaboration, whether among neighbors or software developers.
In approaching the topic of open source license enforcement, it is important to consider Lincoln’s advice. Collaboration during open source license enforcement is a key to successful compliance just as it is an important element to success in the software development process. In assessing license enforcement tactics, you need to ask whether they will foster greater collaboration in open source software development. If the ultimate result of excessive or abusive enforcement is that developers and enterprises are turned off from participating in upstream open source communities, the ecosystems will wither and we all suffer as a result.
Continue reading “Collaboration in open source license enforcement — a community movement is happening”