mtpti5iD/redhat-docs_dataset huggingface dataset:
5.279. Red Hat Enterprise Linux Release Notes 5.279.1. RHEA-2012:0979 - Red Hat Enterprise Linux 6.3 Release Notes Updated packages containing the Release Notes for Red Hat Enterprise Linux 6.3 are now available. Red Hat Enterprise Linux minor releases are an aggregation of individual enhancement, security and bug fix errata. The Red Hat Enterprise Linux 6.3 Release Notes documents the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release. Detailed notes on all changes in this minor release are available in the Technical Notes. Refer to the Online Release Notes for the most up-to-date version of the Red Hat Enterprise Linux 6.3 Release Notes: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.3_Release_Notes/index.html

Commands:
Chapter 1. Operators overview Operators are among the most important components of OpenShift Container Platform. Operators are the preferred method of packaging, deploying, and managing services on the control plane. They can also provide advantages to applications that users run. Operators integrate with Kubernetes APIs and CLI tools such as kubectl and oc commands. They provide the means of monitoring applications, performing health checks, managing over-the-air (OTA) updates, and ensuring that applications remain in your specified state. While both follow similar Operator concepts and goals, Operators in OpenShift Container Platform are managed by two different systems, depending on their purpose: Cluster Operators, which are managed by the Cluster Version Operator (CVO), are installed by default to perform cluster functions. Optional add-on Operators, which are managed by Operator Lifecycle Manager (OLM), can be made accessible for users to run in their applications. With Operators, you can create applications to monitor the running services in the cluster. Operators are designed specifically for your applications. Operators implement and automate the common Day 1 operations such as installation and configuration as well as Day 2 operations such as autoscaling up and down and creating backups. All these activities are in a piece of software running inside your cluster. 1.1. For developers As a developer, you can perform the following Operator tasks: Install Operator SDK CLI . Create Go-based Operators , Ansible-based Operators , Java-based Operators , and Helm-based Operators . Use Operator SDK to build,test, and deploy an Operator . Install and subscribe an Operator to your namespace . Create an application from an installed Operator through the web console . Additional resources Machine deletion lifecycle hook examples for Operator developers 1.2. For administrators As a cluster administrator, you can perform the following Operator tasks: Manage custom catalogs Allow non-cluster administrators to install Operators Install an Operator from OperatorHub View Operator status . Manage Operator conditions Upgrade installed Operators Delete installed Operators Configure proxy support Use Operator Lifecycle Manager on restricted networks To know all about the cluster Operators that Red Hat provides, see Cluster Operators reference . 1.3. steps To understand more about Operators, see What are Operators?

Commands:
Chapter 1. Configuring persistent storage When you deploy Red Hat OpenStack Services on OpenShift (RHOSO), you can configure your deployment to use Red Hat Ceph Storage as the back end for storage and you can configure RHOSO storage services for block, image, object, and file storage. You can integrate an external Red Hat Ceph Storage cluster with the Compute service (nova) and a combination of one or more RHOSO storage services, and you can create a hyperconverged infrastructure (HCI) environment. RHOSO supports Red Hat Ceph Storage 7.1 or later. For information about creating a hyperconverged infrastructure (HCI) environment, see Deploying a hyperconverged infrastructure environment . Note Red Hat OpenShift Data Foundation (ODF) can be used in external mode to integrate with Red Hat Ceph Storage. The use of ODF in internal mode is not supported. For more information on deploying ODF in external mode, see Deploying OpenShift Data Foundation in external mode . RHOSO recognizes two types of storage - ephemeral and persistent: Ephemeral storage is associated with a specific Compute instance. When that instance is terminated, so is the associated ephemeral storage. This type of storage is useful for runtime requirements, such as storing the operating system of an instance. Persistent storage is designed to survive (persist) independent of any running instance. This storage is used for any data that needs to be reused, either by different instances or beyond the life of a specific instance. RHOSO storage services correspond with the following persistent storage types: Block Storage service (cinder): Volumes Image service (glance): Images Object Storage service (swift): Objects Shared File Systems service (manila): Shares All persistent storage services store data in a storage back end. Red Hat Ceph Storage can serve as a back end for all four services, and the features and functionality of OpenStack services are optimized when you use Red Hat Ceph Storage. Storage solutions RHOSO supports the following storage solutions: Configure the Block Storage service with a Ceph RBD back end, iSCSI, FC, or NVMe-TCP storage protocols, or a generic NFS back end. Configure the Image service with a Ceph RBD, Block Storage, Object Storage, or NFS back end. Configure the Object Storage service to use PersistentVolumes (PVs) on OpenShift nodes or disks on external data plane nodes. Configure the Shared File Systems service with a native CephFS, Ceph-NFS, or alternative back end, such as NetApp or Pure Storage. For information about planning the storage solution and related requirements for your RHOSO deployment, for example, networking and security, see Planning storage and shared file systems in Planning your deployment . To promote the use of best practices, Red Hat has a certification process for OpenStack back ends. For improved supportability and interoperability, ensure that your storage back end is certified for RHOSO. You can check certification status in the Red Hat Ecosystem Catalog . Ceph RBD is certified as a back end in all RHOSO releases.

Commands:
B.61. openssh B.61.1. RHBA-2010:0943 - openssh bug fix update Updated openssh packages that fix two bugs are now available for Red Hat Enterprise Linux 6. OpenSSH is OpenBSD's SSH (Secure Shell) protocol implementation. These packages include the core files necessary for both the OpenSSH client and server. Bug Fixes BZ# 651820 When the ~/.bashrc startup file contained a command that produced an output to standard error (STDERR), the sftp utility was unable to log in to that account. This bug has been fixed, and the output to STDERR no longer prevents sftp from establishing the connection. BZ# 655043 Prior to this update, the authentication based on a GSS key exchange did not work, rendering users unable to authenticate using this method. With this update, the underlying source code has been modified to target this issue, and the GSSKEX-based authentication now works as expected. All OpenSSH users are advised to upgrade to these updated packages, which resolve these issues.

Commands:
Chapter 1. Overview AMQ Spring Boot Starter is an adapter for creating Spring-based applications that use AMQ messaging. It provides a Spring Boot starter module that enables you to build standalone Spring applications. The starter uses the Red Hat build of Apache Qpid JMS client to communicate using the AMQP 1.0 protocol. This release supports jakarta.jms and requires Java version 17 or higher. For javax.jms support, see the 2.x release of AMQ Spring Boot Starter. AMQ Spring Boot Starter is based on the AMQP 1.0 JMS Spring Boot project. 1.1. Key features Quickly build standalone Spring applications with built-in messaging Automatic configuration of JMS resources Configurable pooling of JMS connections and sessions 1.2. Supported standards and protocols Version 3.1 of the Spring Boot API Version 2.0 of the Java Message Service API Version 1.0 of the Advanced Message Queueing Protocol (AMQP) 1.3. Supported configurations Refer to Red Hat AMQ Supported Configurations on the Red Hat Customer Portal for current information regarding AMQ Spring Boot Starter supported configurations. 1.4. Document conventions The sudo command In this document, sudo is used for any command that requires root privileges. Exercise caution when using sudo because any changes can affect the entire system. For more information about sudo , see Using the sudo command . File paths In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/andrea ). On Microsoft Windows, you must use the equivalent Windows paths (for example, C:\Users\andrea ). Variable text This document contains code blocks with variables that you must replace with values specific to your environment. Variable text is enclosed in arrow braces and styled as italic monospace. For example, in the following command, replace <project-dir> with the value for your environment: USD cd <project-dir>

Commands:
cd <project-dir>
Chapter 2. Deploying Red Hat build of OpenJDK application in containers You can deploy Red Hat build of OpenJDK applications in containers and have them run when the container is loaded. Procedure Copy the application JAR to the /deployments directory in the image JAR file. For example, the following shows a brief Dockerfile that adds an application called testubi.jar to the Red Hat build of OpenJDK 17 UBI8 image:

Commands:
FROM registry.access.redhat.com/ubi8/openjdk-17 COPY target/testubi.jar /deployments/testubi.jar
8.132. openhpi 8.132.1. RHBA-2013:1532 - openhpi bug fix update Updated openhpi packages that fix several bugs are now available for Red Hat Enterprise Linux 6. OpenHPI provides an open source implementation of the Service Availability Forum (SAF) Hardware Platform Interface (HPI). HPI is an abstracted interface for managing computer hardware, typically chassis- and rack-based servers. HPI includes resource modeling; access to and control over sensor, control, watchdog, and inventory data associated with resources; abstracted System Event Log interfaces; hardware events and alarms; and a managed hot swap interface. Bug Fixes BZ# 891626 Due to a bug in the power_supply() parsing routines, some returned strings could contain incorrectly displayed characters. Consequently, retrieving a serial or part number of a power supply unit (PSU) via the OpenHPI API resulted in strings containing these characters. This update ensures that proper serial and part numbers are returned for PSUs and the returned strings now only contain valid characters. BZ# 924852 Previously, code supporting certain RDR (Request Data with Reply) sensors was missing in OpenHPI. Consequently, after the extraction and reinsertion of an enclosure monitored via the Onboard Administrator (OA) SOAP plug-in, the following error messages were returned to the log file: openhpid: ERROR: (oa_soap_sensor.c, 2005, RDR not present) openhpid: ERROR: (oa_soap_fan_event.c, 279, processing the sensor event for sensor 24 has failed) This bug has been fixed and no error messages are now logged after a component is extracted and reinserted. BZ# 948386 Under certain conditions, when using OpenHPI with the Onboard Administrator (OA) SOAP plug-in when an OA switch-over took place, HPI clients became unresponsive or the openhpi daemon failed to connect to the new active OA. Consequently, clients were unable to retrieve events and data. A series of patches has been provided to better account for OA failover situations, thus fixing this bug. BZ# 953515 Prior to this update, support for certain blade servers was missing in OpenHPI. Consequently, the OpenHPI daemon terminated unexpectedly with a segmentation fault at startup on these servers. A patch has been provided to add the missing support and the OpenHPI daemon no longer crashes in the described scenario. BZ# 953525 Due to missing support for certain thermal sensors, the getBladeInfo() function could terminate unexpectedly, causing the whole discovery process to fail. This update adds the support for these sensors and OpenHPI discovery now works as expected. Users of openhpi are advised to upgrade to these updated packages, which fix these bugs.

Commands:
4.81. gpxe 4.81.1. RHBA-2011:1765 - gpxe bug fix update Updated gpxe packages that fix one bug are now available for Red Hat Enterprise Linux 6. The gpxe packages provide an open source Preboot Execution Environment (PXE) implementation and bootloader. gPXE also supports additional protocols such as DNS, HTTP, iSCSI and ATA over Ethernet. Bug Fix BZ# 743893 Prior to this update, PXE failed to boot a virtual machine which used the virtio network interface card (NIC). An upstream patch, which incorporates the latest upstream gPXE paravirtualized network adapter (virtio-net) driver and removes the legacy Etherboot virtio-net driver, has been applied to fix this problem. Now, PXE can successfully boot virtual machines that use virtio NIC. All users of gpxe are advised to upgrade to these updated packages, which fix this bug.

Commands:
5.69. firstboot 5.69.1. RHEA-2012:0928 - firstboot enhancement update Updated firstboot packages that add two enhancements are now available for Red Hat Enterprise Linux 6. The firstboot utility runs after installation and guides the user through a series of steps that allows for easier configuration of the machine. Enhancements BZ# 704187 Prior to this update, the firstboot utility did not allow users to change the timezone. This update adds the timezone module to firstboot so that users can now change the timezone in the reconfiguration mode. BZ# 753658 Prior to this update, the firstboot service did not provide a status option. This update adds the "firstboot service status" option to show if firstboot is scheduled to run on the boot or not. All users of firstboot are advised to upgrade to these updated packages, which add these enhancements.

Commands:
4.2. Local Transactions A connection uses the autoCommit flag to explicitly control local transactions. By default, autoCommit is set to true , which indicates request level or implicit transaction control: This example demonstrates several things: Setting autoCommit flag to false. This will start a transaction bound to the connection. Executing multiple updates within the context of the transaction. When the statements are complete, the transaction is committed by calling commit() . If an error occurs, the transaction is rolled back using the rollback() method.

Commands:
// Set auto commit to false and start a transaction connection.setAutoCommit(false); try { // Execute multiple updates Statement statement = connection.createStatement(); statement.executeUpdate("INSERT INTO Accounts (ID, Name) VALUES (10, 'Mike'\u0099)"); statement.executeUpdate("INSERT INTO Accounts (ID, Name) VALUES (15, 'John'\u0099)"); statement.close(); // Commit the transaction connection.commit(); } catch(SQLException e) { // If an error occurs, rollback the transaction connection.rollback(); }
Chapter 1. OpenShift Virtualization Engine overview OpenShift Virtualization Engine , an edition of Red Hat OpenShift, is an enterprise-grade virtualization solution for organizations that need a scalable, reliable platform for running and managing virtual machines (VMs). It integrates with your existing IT infrastructure to support VM-exclusive workloads, including those requiring consistent VM performance. 1.1. About OpenShift Virtualization Engine While all editions of Red Hat OpenShift include OpenShift Virtualization , OpenShift Virtualization Engine is a cost-effective, virtualization-only option that does not include container-based or cloud-native features for applications. If you migrate from a traditional virtualization platform to OpenShift Virtualization Engine, you can add containerization and modernization features later by switching to a different edition of Red Hat OpenShift. Note OpenShift Virtualization Engine supports hosting infrastructure services in containers. For more information, see the Self-managed Red Hat OpenShift subscription guide . To simplify migration and VM management, OpenShift Virtualization Engine integrates with the following tools and capabilities: Red Hat Ansible Automation Platform Enables automation at scale, streamlining tasks such as VM provisioning, migration, monitoring, and management. Red Hat Advanced Cluster Management for Virtualization Provides a centralized platform to manage VMs throughout their lifecycle and across clusters. Using a centralized management platform can ensure consistency and compliance, especially for organizations that require robust governance and automated policy enforcement. Demo: Manage and monitor VMs on OpenShift with ACM Red Hat partner ecosystem You can complete your virtualization solution with offerings from Red Hat partners in areas such as networking and disaster recovery. 1.2. Additional resources OpenShift Virtualization documentation OpenShift Virtualization Engine product page Self-managed Red Hat OpenShift subscription guide Virtual infrastructure management with Red Hat Ansible Automation Platform Red Hat Advanced Cluster Management for Kubernetes Migration Toolkit for Virtualization Red Hat OpenShift Virtualization in the Red Hat Ecosystem Catalog 1.3. Get support for OpenShift Virtualization Engine Red Hat offers cluster administrator tools for gathering data, monitoring, and troubleshooting your cluster. If you need help with your OpenShift Virtualization Engine solution, log a case in the appropriate product by using its subscription name. See the Red Hat customer support portal to open a support case.

Commands:
19.3.3. Restoring access to a volume After the encryption keys have been saved (see Section 19.3.1, "Preparation for saving encryption keys" and Section 19.3.2, "Saving encryption keys" ), access can be restored to a driver where needed. Procedure 19.5. Restoring access to a volume Get the escrow packet for the volume from the packet storage and send it to one of the designated users for decryption. The designated user runs: After providing the NSS database password, the designated user chooses a passphrase for encrypting escrow-packet-out . This passphrase can be different every time and only protects the encryption keys while they are moved from the designated user to the target system. Obtain the escrow-packet-out file and the passphrase from the designated user. Boot the target system in an environment that can run volume_key and have the escrow-packet-out file available, such as in a rescue mode. Run: A prompt will appear for the packet passphrase chosen by the designated user, and for a new passphrase for the volume. Mount the volume using the chosen volume passphrase. It is possible to remove the old passphrase that was forgotten by using cryptsetup luksKillSlot , for example, to free up the passphrase slot in the LUKS header of the encrypted volume. This is done with the command cryptsetup luksKillSlot device key-slot . For more information and examples see cryptsetup --help .

Commands:
volume_key --reencrypt -d /the/nss/directory escrow-packet-in -o escrow-packet-out
volume_key --restore /path/to/volume escrow-packet-out
A.2. Wake-ups Many applications scan configuration files for changes. In many cases, the scan is performed at a fixed interval, for example, every minute. This can be a problem, because it forces a disk to wake up from spindowns. The best solution is to find a good interval, a good checking mechanism, or to check for changes with inotify and react to events. Inotify can check variety of changes on a file or a directory. For example: #include <stdio.h> #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> #include <sys/inotify.h> #include <unistd.h> int main(int argc, char *argv[]) { int fd; int wd; int retval; struct timeval tv; fd = inotify_init(); /* checking modification of a file - writing into */ wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY); if (wd < 0) { printf("inotify cannot be used\n"); /* switch back to checking */ } fd_set rfds; FD_ZERO(&rfds); FD_SET(fd, &rfds); tv.tv_sec = 5; tv.tv_usec = 0; retval = select(fd + 1, &rfds, NULL, NULL, &tv); if (retval == -1) perror("select()"); else if (retval) { printf("file was modified\n"); } else printf("timeout\n"); return EXIT_SUCCESS; } The advantage of this approach is the variety of checks that you can perform. The main limitation is that only a limited number of watches are available on a system. The number can be obtained from /proc/sys/fs/inotify/max_user_watches and although it can be changed, this is not recommended. Furthermore, in case inotify fails, the code has to fall back to a different check method, which usually means many occurrences of #if #define in the source code. For more information on inotify , see the inotify(7) man page.

Commands:
#include <stdio.h> #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> #include <sys/inotify.h> #include <unistd.h> int main(int argc, char *argv[]) { int fd; int wd; int retval; struct timeval tv; fd = inotify_init(); /* checking modification of a file - writing into */ wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY); if (wd < 0) { printf("inotify cannot be used\n"); /* switch back to previous checking */ } fd_set rfds; FD_ZERO(&rfds); FD_SET(fd, &rfds); tv.tv_sec = 5; tv.tv_usec = 0; retval = select(fd + 1, &rfds, NULL, NULL, &tv); if (retval == -1) perror("select()"); else if (retval) { printf("file was modified\n"); } else printf("timeout\n"); return EXIT_SUCCESS; }
Chapter 43. Installation and Booting Custom system image creation with Image Builder available as a Technology Preview The Image Builder tool enables users to create customized RHEL images. Starting with Red Hat Enterprise Linux 7.6, Image Builder is available in the Extras channel as a Technology Preview in the lorax-composer package. With Image Builder, users can create custom system images which include additional packages. Composer functionality can be accessed through a graphical user interface in Web Console, or with a command line interface in the composer-cli tool. Image Builder output formats include, among others: ISO disk image qcow2 file for direct use with a virtual machine file system image file To learn more about Image Builder, see the Image Builder Guide . (BZ#1613966)

Commands:
Chapter 61. KafkaExporterSpec schema reference Used in: KafkaSpec Property Description image The docker image for the pods. string groupRegex Regular expression to specify which consumer groups to collect. Default value is .* . string topicRegex Regular expression to specify which topics to collect. Default value is .* . string groupExcludeRegex Regular expression to specify which consumer groups to exclude. string topicExcludeRegex Regular expression to specify which topics to exclude. string resources CPU and memory resources to reserve. For more information, see the external documentation for core/v1 resourcerequirements . ResourceRequirements logging Only log messages with the given severity or above. Valid levels: [ info , debug , trace ]. Default log level is info . string enableSaramaLogging Enable Sarama logging, a Go client library used by the Kafka Exporter. boolean template Customization of deployment templates and pods. KafkaExporterTemplate livenessProbe Pod liveness check. Probe readinessProbe Pod readiness check. Probe

Commands: