mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Planned changes to naming convention for Windows build artifacts From October 2024 onward, Red Hat plans to introduce naming changes for some files that are distributed as part of Red Hat build of OpenJDK releases for Windows Server platforms. These file naming changes will affect both the .zip archive and .msi installers that Red Hat provides for the JDK, JRE and debuginfo packages for Red Hat build of OpenJDK versions 8, 11, and 17. The aim of this change is to adopt a common naming convention that is consistent across all versions of OpenJDK that Red Hat supports. Red Hat build of OpenJDK versions 8, 11, and 17 will be aligned with the naming convention that Red Hat has already adopted for Red Hat build of OpenJDK 21. This means that Red Hat build of OpenJDK 21 will not require any naming changes. These planned changes do not affect the files for the Linux portable builds of any Red Hat build of OpenJDK version. Red Hat build of OpenJDK 8.0.422 is the last release where Red Hat plans to use the old naming convention for Windows artifacts. The following list provides an example of how the planned naming changes will affect each file for future releases of Red Hat build of OpenJDK 8: MSI installer Old file name: java-1.8.0-openjdk-1.8.0. <version> .redhat.windows.x86_64.msi New file name: java-1.8.0-openjdk-1.8.0. <version> .win.x86_64.msi .zip archive for JDK package Old file name: java-1.8.0-openjdk-1.8.0. <version> .redhat.windows.x86_64.zip New file name: java-1.8.0-openjdk-1.8.0. <version> .win.jdk.x86_64.zip .zip archive for for JRE package Old file name: java-1.8.0-openjdk-jre-1.8.0. <version> .redhat.windows.x86_64.zip New file name: java-1.8.0-openjdk-1.8.0. <version> .win.jre.x86_64.zip .zip archive for debuginfo package Old file name: java-1.8.0-openjdk-1.8.0. <version> .redhat.windows.x86_64.debuginfo.zip New file name: java-1.8.0-openjdk-1.8.0. <version> .win.debuginfo.x86_64.zip

Commands:
Chapter 5. Securing a service network Skupper provides default, built-in security that scales across clusters and clouds. This section describes additional security you can configure. See Securing a service network using policies for information about creating granular policies for each cluster. 5.1. Restricting access to services using a Kubernetes network policy By default, if you expose a service on the service network, that service is also accessible from other namespaces in the cluster. You can avoid this situation when creating a site using the --create-network-policy option. Procedure Create the service network router with a Kubernetes network policy: USD skupper init --create-network-policy Check the site status: USD skupper status The output should be similar to the following: You can now expose services on the service network and those services are not accessible from other namespaces in the cluster. 5.2. Applying TLS to TCP or HTTP2 traffic on the service network By default, the traffic between sites is encrypted, however the traffic between the service pod and the router pod is not encrypted. For services exposed as TCP or HTTP2, the traffic between the pod and the router pod can be encrypted using TLS. Prerequisites Two or more linked sites A TCP or HTTP2 frontend and backend service Procedure Deploy your backend service. Expose your backend deployment on the service network, enabling TLS. For example, if you want to expose a TCP service: USD skupper expose deployment <deployment-name> --port 443 --enable-tls Enabling TLS creates the necessary certificates required for TLS backends and stores them in a secret named skupper-tls-<deployment-name> . Modify the backend deployment to include the generated certificates, for example: ... spec: containers: ... command: ... - "/certs/tls.key" - "/certs/tls.crt" ... volumeMounts: ... - mountPath: /certs name: certs readOnly: true volumes: - name: index-html configMap: name: index-html - name: certs secret: secretName: skupper-tls-<deployment-name> Each site creates the necessary certificates required for TLS clients and stores them in a secret named skupper-service-client . Modify the frontend deployment to include the generated certificates, for example: spec: template: spec: containers: ... volumeMounts: - name: certs mountPath: /tmp/certs/skupper-service-client ... volumes: - name: certs secret: secretName: skupper-service-client Test calling the service from a TLS enabled frontend.

Commands:
skupper init --create-network-policy
skupper status
Skupper enabled for namespace 'west'. It is not connected to any other sites.
skupper expose deployment <deployment-name> --port 443 --enable-tls
spec: containers: command: - "/certs/tls.key" - "/certs/tls.crt" volumeMounts: - mountPath: /certs name: certs readOnly: true volumes: - name: index-html configMap: name: index-html - name: certs secret: secretName: skupper-tls-<deployment-name>
spec: template: spec: containers: volumeMounts: - name: certs mountPath: /tmp/certs/skupper-service-client volumes: - name: certs secret: secretName: skupper-service-client
7.46. e2fsprogs 7.46.1. RHBA-2013:0455 - e2fsprogs bug fix update Updated e2fsprogs packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The e2fsprogs packages provide a number of utilities for creating, checking, modifying, and correcting any inconsistencies in the ext2 file systems. Bug Fixes BZ#806137 On a corrupted file system, the "mke2fs -S" command could remove files instead of attempting to recover them. This bug has been fixed; the "mke2fs -S" command writes metadata properly and no longer removes files instead of recovering them. BZ# 813820 The resize2fs(8) man page did not list an ext4 file system as capable of on-line resizing. This omission has been fixed and the resize2fs(8) man page now includes all file systems that can be resized on-line. BZ#858338 A special flag was used to indicate blocks allocated beyond the end of file on an ext4 file system. This flag was sometimes mishandled, resulting in file system corruption. Both the kernel and user space have been reworked to eliminate the use of this flag. Enhancement BZ#824126 Previously, users could use the e2fsck utility on a mounted file system, although it was strongly recommended not to do so. Using the utility on a mounted file system led to file system corruption. With this update, e2fsck opens the file system exclusively and fails when the file system is busy. This behavior avoids possible corruption of the mounted file system. Users of e2fsprogs are advised to upgrade to these updated packages, which fix these bugs and add this enhancement 7.46.2. RHBA-2013:1502 - e2fsprogs bug fix update Updated e2fsprogs packages that fix one bug are now available for Red Hat Enterprise Linux 6. The e2fsprogs packages provide a number of utilities for creating, checking, modifying, and correcting any inconsistencies in the ext2 file systems. Bug Fix BZ# 1023351 The resize2fs utility did not properly handle resizing of an ext4 file system to a smaller size. As a consequence, files containing many extents could become corrupted if they were moved during the resize process. With this update, resize2fs now maintains a consistent extent tree when moving files containing many extents, and such files no longer become corrupted in this scenario. Users of e2fsprogs are advised to upgrade to these updated packages, which fix this bug. 7.46.3. RHBA-2013:0970 - e2fsprogs bug fix update Updated e2fsprogs packages that fix one bug are now available for Red Hat Enterprise Linux 6. The e2fsprogs packages provide a number of utilities for creating, checking, modifying, and correcting any inconsistencies in the ext2 file systems. Bug Fix BZ# 974193 Some ext4 extent tree corruptions were not detected or repaired by e2fsck. Inconsistencies related to overlapping interior or leaf nodes in the extent tree were not detected, and the file system remained in an inconsistent state after an e2fsck. These inconsistencies were then detected by the kernel at run time. e2fsck is now able to detect and repair this class of corruptions in the file system. Users of e2fsprogs are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 3. Installing the Cluster Observability Operator As a cluster administrator, you can install or remove the Cluster Observability Operator (COO) from OperatorHub by using the OpenShift Container Platform web console. OperatorHub is a user interface that works in conjunction with Operator Lifecycle Manager (OLM), which installs and manages Operators on a cluster. 3.1. Installing the Cluster Observability Operator in the web console Install the Cluster Observability Operator (COO) from OperatorHub by using the OpenShift Container Platform web console. Prerequisites You have access to the cluster as a user with the cluster-admin cluster role. You have logged in to the OpenShift Container Platform web console. Procedure In the OpenShift Container Platform web console, click Operators OperatorHub . Type cluster observability operator in the Filter by keyword box. Click Cluster Observability Operator in the list of results. Read the information about the Operator, and configure the following installation settings: Update channel stable Version 1.0.0 or later Installation mode All namespaces on the cluster (default) Installed Namespace Operator recommended Namespace: openshift-cluster-observability-operator Select Enable Operator recommended cluster monitoring on this Namespace Update approval Automatic Optional: You can change the installation settings to suit your requirements. For example, you can select to subscribe to a different update channel, to install an older released version of the Operator, or to require manual approval for updates to new versions of the Operator. Click Install . Verification Go to Operators Installed Operators , and verify that the Cluster Observability Operator entry appears in the list. Additional resources Adding Operators to a cluster 3.2. Uninstalling the Cluster Observability Operator using the web console If you have installed the Cluster Observability Operator (COO) by using OperatorHub, you can uninstall it in the OpenShift Container Platform web console. Prerequisites You have access to the cluster as a user with the cluster-admin cluster role. You have logged in to the OpenShift Container Platform web console. Procedure Go to Operators Installed Operators . Locate the Cluster Observability Operator entry in the list. Click for this entry and select Uninstall Operator . Verification Go to Operators Installed Operators , and verify that the Cluster Observability Operator entry no longer appears in the list.

Commands:
Introduction This document provides a high-level overview of the High Availability Add-On for Red Hat Enterprise Linux 6. Although the information in this document is an overview, you should have advanced working knowledge of Red Hat Enterprise Linux and understand the concepts of server computing to gain a good comprehension of the information. For more information about using Red Hat Enterprise Linux see the following resources: Red Hat Enterprise Linux Installation Guide - Provides information regarding installation of Red Hat Enterprise Linux 6. Red Hat Enterprise Linux Deployment Guide - Provides information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 6. For more information about this and related products for Red Hat Enterprise Linux 6, see the following resources: Configuring and Managing the High Availability Add-On Provides information about configuring and managing the High Availability Add-On (also known as Red Hat Cluster) for Red Hat Enterprise Linux 6. Logical Volume Manager Administration - Provides a description of the Logical Volume Manager (LVM), including information on running LVM in a clustered environment. Global File System 2: Configuration and Administration - Provides information about installing, configuring, and maintaining Red Hat GFS2 (Red Hat Global File System 2), which is included in the Resilient Storage Add-On. DM Multipath - Provides information about using the Device-Mapper Multipath feature of Red Hat Enterprise Linux 6. Load Balancer Administration - Provides information on configuring high-performance systems and services with the Red Hat Load Balancer Add-On (Formerly known as Linux Virtual Server [LVS]). Release Notes - Provides information about the current release of Red Hat products. Note For information on best practices for deploying and upgrading Red Hat Enterprise Linux clusters using the High Availability Add-On and Red Hat Global File System 2 (GFS2) see the article "Red Hat Enterprise Linux Cluster, High Availability, and GFS Deployment Best Practices" on Red Hat Customer Portal at . https://access.redhat.com/kb/docs/DOC-40821 . This document and other Red Hat documents are available in HTML, PDF, and RPM versions online at https://access.redhat.com/documentation/en/red-hat-enterprise-linux/ . 1. We Need Feedback! If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/ against the product Red Hat Enterprise Linux 6 , the component doc-High_Availability_Add-On_Overview and version number: 6.9 . If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, include the section number and some of the surrounding text so we can find it easily.

Commands:
Chapter 105. OtherArtifact schema reference Used in: Plugin Property Property type Description type string Must be other . url string URL of the artifact which will be downloaded. Streams for Apache Kafka does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for jar , zip , tgz and other artifacts. Not applicable to the maven artifact type. sha512sum string SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the maven artifact type. fileName string Name under which the artifact will be stored. insecure boolean By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to true , all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.

Commands:
Chapter 2. Running Java applications with Shenandoah garbage collector You can run your Java application with the Shenandoah garbage collector (GC). Prerequisites Installed Red Hat build of OpenJDK. See Installing Red Hat build of OpenJDK 8 on Red Hat Enterprise Linux in the Installing and using Red Hat build of OpenJDK 8 on RHEL guide. Procedure Run your Java application with Shenandoah GC by using the -XX:+UseShenandoahGC JVM option. USD java <PATH_TO_YOUR_APPLICATION> -XX:+UseShenandoahGC

Commands:
java <PATH_TO_YOUR_APPLICATION> -XX:+UseShenandoahGC
5.224. oprofile 5.224.1. RHBA-2012:0966 - oprofile bug fix and enhancement update Updated oprofile packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. OProfile is a system-wide profiler for Linux systems. The profiling runs transparently in the background and profile data can be collected at any time. OProfile uses the hardware performance counters provided on many processors, and can use the Real Time Clock (RTC) for profiling on processors without counters. The oprofile packages have been upgraded to upstream version 0.9.7, which provides a number of bug fixes and enhancements over the version. (BZ# 739142 ) Bug Fix BZ# 748789 Under certain circumstances, the "opannotate" and "opreport" commands reported no results. With this update, this problem has been fixed so that these commands work as expected. All OProfile users are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 1. Quay.io overview Quay.io is a registry for storing, building, and distributing container images and other OCI artifacts. Quay.io has gained widespread popularity among developers, organizations, and enterprises for establishing itself as one of the leading platforms in the containerization ecosystem. It offers both free and paid tiers to cater to various user needs. At its core, Quay.io serves as a centralized repository for storing, managing, and distributing container images. Quay.io is flexible, easy to use, and offers an intuitive web interface that allows users to quickly upload and manage their container images. Developers can create private repositories, ensuring sensitive or proprietary code remains secure within their organization. Additionally, users can set up access controls and manage team collaboration, enabling seamless sharing of container images among designated team members. Quay.io addresses container security concerns through its integrated image scanner, Clair . The service automatically scans container images for known vulnerabilities and security issues, providing developers with valuable insights into potential risks and suggesting remediation steps. Quay.io excels in automation and supports integration with popular Continuous Integration/Continuous Deployment (CI/CD) tools and platforms, enabling seamless automation of the container build and deployment processes. As a result, developers can streamline their workflows, significantly reducing manual intervention and improving overall development efficiency. Quay.io caters to the needs of both large and small-scale deployments. Its architecture and support for high availability ensures that organizations can rely on it for mission-critical applications. The platform can handle significant container image traffic and offers efficient replication and distribution mechanisms to deliver container images to various geographical locations. Quay.io has established itself as an active hub for container enthusiasts. Developers can discover a vast collection of pre-built, public container images shared by other users, making it easier to find useful tools, applications, and services for their projects. This open sharing ecosystem fosters collaboration and accelerates software development within the container community. As containerization continues to gain momentum in the software development landscape, Quay.io remains at the forefront, continually improving and expanding its services. The platform's commitment to security, ease of use, automation, and community engagement has solidified its position as a preferred container registry service for both individual developers and large organizations alike.

Commands:
Part I. Designing a decision service using DMN models As a business analyst or business rules developer, you can use Decision Model and Notation (DMN) to model a decision service graphically. The decision requirements of a DMN decision model are determined by a decision requirements graph (DRG) that is depicted in one or more decision requirements diagrams (DRDs). A DRD can represent part or all of the overall DRG for the DMN model. DRDs trace business decisions from start to finish, with each decision node using logic defined in DMN boxed expressions such as decision tables. Red Hat Process Automation Manager provides runtime support for DMN 1.1, 1.2, 1.3, and 1.4 models at conformance level 3, and design support for DMN 1.2 models at conformance level 3. You can design your DMN models directly in Business Central or with the Red Hat Process Automation Manager DMN modeler in VS Code, or import existing DMN models into your Red Hat Process Automation Manager projects for deployment and execution. Any DMN 1.1 and 1.3 models (do not contain DMN 1.3 features) that you import into Business Central, open in the DMN designer, and save are converted to DMN 1.2 models. For more information about DMN, see the Object Management Group (OMG) Decision Model and Notation specification . For a step-by-step tutorial with an example DMN decision service, see Getting started with decision services .

Commands:
7.263. vgabios 7.263.1. RHBA-2013:0487 - vgabios bug fix update An updated vgabios package that fixes one bug is now available for Red Hat Enterprise Linux 6. The vgabios package provides a GNU Lesser General Public License (LPGL) implementation of a BIOS for video cards. The vgabios package contains BIOS images that are intended to be used in the Kernel Virtual Machine (KVM). Bug Fix BZ# 840087 Previously, an attempt to boot a Red Hat Enterprise Virtualization Hypervisor ISO in a virtual machine was unsuccessful. The boot menu appeared but then stopped responding. The underlying source code has been modified and the virtual machine now works as expected in the described scenario. All users of vgabios are advised to upgrade to this updated package, which fixes this bug.

Commands:
probe::scsi.ioexecute Name probe::scsi.ioexecute - Create mid-layer SCSI request and wait for the result Synopsis scsi.ioexecute Values host_no The host number channel The channel number data_direction The data_direction specifies whether this command is from/to the device. lun The lun number retries Number of times to retry request device_state_str The current state of the device, as a string data_direction_str Data direction, as a string dev_id The scsi device id request_buffer The data buffer address request_bufflen The data buffer buffer length device_state The current state of the device timeout Request timeout in seconds

Commands:
Chapter 1. Custom triggers The Cryostat 3.0 agent supports custom triggers that are based on MBean metric values. You can configure the Cryostat agent to start JFR recordings dynamically when these custom trigger conditions are met. You can define a custom trigger condition that dynamically starts a JFR recording when this condition is met. A custom trigger condition is based on MBean counters that can cover a range of runtime, memory, thread, and operating system metrics. You can include one or more MBean counter types as part of the custom trigger condition for a JFR recording. You can also specify a duration or time period as part of the trigger condition, which means the conditional values must persist for the specified duration before the condition is met. The Cryostat agent supports smart triggers that continually listen to the value of the specified MBean counters. Triggering occurs if the current values of the specified counters match the configured values in the custom trigger for the specified duration. If triggering occurs, the Cryostat agent dynamically starts the JFR recording at that point. Note A JFR recording will not start dynamically if the custom trigger condition associated with this recording is not met.

Commands: