mtpti5iD/redhat-docs_dataset huggingface dataset:
7.233. xkeyboard-config 7.233.1. RHBA-2015:1276 - xkeyboard-config bug fix and enhancement update Updated xkeyboard-config packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The xkeyboard-config packages contain configuration data used by the X keyboard Extension (XKB), which allows selection of keyboard layouts when using a graphical interface. Bug Fixes BZ# 923160 With the upgrade to upstream version 2.11, the /usr/share/X11/xkb/keymap.dir file was removed from the xkeyboard-config packages. Consequently, X11 keyboard configuration stopped working for NX connections. This update includes the missing file again, and as a result, the broken functionality is restored. BZ# 1164507 The upgrade to upstream version 2.11 also remapped three keys in the Russian phonetic keyboard layout: the "x" key was mapped to "ha", "h" to "che", and "=" to the soft sign. This change caused problems to users who expected the usual layout of the phonetic keyboard. Now, the layout has been fixed, and these keys are correctly mapped to the soft sign, "ha", and "che" respectively. Users of xkeyboard-config are advised to upgrade to these updated packages, which fix these bugs.

Commands:
7.6. Running Red Hat JBoss Data Grid JBoss Data Grid can be run in one of three ways: Use the following command to run JBoss Data Grid using the configuration defined in the standalone.xml file (located at USDJDG_HOME/standalone/configuration ): Use the following command with an appended -c followed by the configuration file name to run JBoss Data Grid with a non-default configuration file: Use the following command to run JBoss Data Grid with a default clustered configuration: Report a bug

Commands:
USDJDG_HOME/bin/standalone.sh
USDJDG_HOME/bin/standalone.sh -c clustered.xml
USDJDG_HOME/bin/clustered.sh
Chapter 13. Enabling GPU support in OpenShift AI Optionally, to ensure that your data scientists can use compute-heavy workloads in their models, you can enable graphics processing units (GPUs) in OpenShift AI. Important The NVIDIA GPU Add-on is no longer supported. Instead, enable GPUs by installing the NVIDIA GPU Operator. If your deployment has a previously-installed NVIDIA GPU Add-on, before you install the NVIDIA GPU Operator, use Red Hat OpenShift Cluster Manager to uninstall the NVIDIA GPU Add-on from your cluster. Prerequisites You have logged in to your OpenShift cluster. You have the cluster-admin role in your OpenShift cluster. Procedure To enable GPU support on an OpenShift cluster, follow the instructions here: NVIDIA GPU Operator on Red Hat OpenShift Container Platform in the NVIDIA documentation. Delete the migration-gpu-status ConfigMap. In the OpenShift web console, switch to the Administrator perspective. Set the Project to All Projects or redhat-ods-applications to ensure you can see the appropriate ConfigMap. Search for the migration-gpu-status ConfigMap. Click the action menu (...) and select Delete ConfigMap from the list. The Delete ConfigMap dialog appears. Inspect the dialog and confirm that you are deleting the correct ConfigMap. Click Delete . Restart the dashboard replicaset. In the OpenShift web console, switch to the Administrator perspective. Click Workloads Deployments . Set the Project to All Projects or redhat-ods-applications to ensure you can see the appropriate deployment. Search for the rhods-dashboard deployment. Click the action menu (...) and select Restart Rollout from the list. Wait until the Status column indicates that all pods in the rollout have fully restarted. Verification The NVIDIA GPU Operator appears on the Operators Installed Operators page in the OpenShift web console. The reset migration-gpu-status instance is present in the Instances tab on the AcceleratorProfile custom resource definition (CRD) details page. After installing the NVIDIA GPU Operator, create an accelerator profile as described in Working with accelerator profiles .

Commands:
Chapter 13. Installing a three-node cluster on GCP In OpenShift Container Platform version 4.15, you can install a three-node cluster on Google Cloud Platform (GCP). A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 13.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 13.2. steps Installing a cluster on GCP with customizations Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
21.2.2.2. The /etc/selinux/ Directory The /etc/selinux/ directory is the primary location for all policy files as well as the main configuration file. The following example shows sample contents of the /etc/selinux/ directory: The two subdirectories, strict/ and targeted/ , are the specific directories where the policy files of the same name (i.e., strict and targeted) are contained. For more information on SELinux policy and policy configuration, refer to the rhel-selg.

Commands:
-rw-r--r-- 1 root root 448 Sep 22 17:34 config drwxr-xr-x 5 root root 4096 Sep 22 17:27 strict drwxr-xr-x 5 root root 4096 Sep 22 17:28 targeted
17.12. Saving and Restoring the Network Configuration The command line version of Network Administration Tool can be used to save the system's network configuration to a file. This file can then be used to restore the network settings to a Red Hat Enterprise Linux system. This feature can be used as part of an automated backup script, to save the configuration before upgrading or reinstalling, or to copy the configuration to a different Red Hat Enterprise Linux system. To save, or export , the network configuration of a system to the file /tmp/network-config , execute the following command as root: To restore, or import , the network configuration from the file created from the command, execute the following command as root: The -i option means to import the data, the -c option means to clear the existing configuration prior to importing, and the -f option specifies that the file to import is as follows.

Commands:
system-config-network-cmd -e > /tmp/network-config
system-config-network-cmd -i -c -f /tmp/network-config
13.2. Creating a Partition Warning Do not attempt to create a partition on a device that is in use. Procedure 13.1. Creating a partition Before creating a partition, boot into rescue mode (or unmount any partitions on the device and turn off any swap space on the device). Start parted , where /dev/ sda is the device on which to create the partition: View the current partition table to determine if there is enough free space: If there is not enough free space, you can resize an existing partition. Refer to Section 13.4, "Resizing a Partition" for details. 13.2.1. Making the Partition From the partition table, determine the start and end points of the new partition and what partition type it should be. You can only have four primary partitions (with no extended partition) on a device. If you need more than four partitions, you can have three primary partitions, one extended partition, and multiple logical partitions within the extended. For an overview of disk partitions, refer to the appendix An Introduction to Disk Partitions in the Red Hat Enterprise Linux 6 Installation Guide . For example, to create a primary partition with an ext3 file system from 1024 megabytes until 2048 megabytes on a hard drive type the following command: Note If you use the mkpartfs command instead, the file system is created after the partition is created. However, parted does not support creating an ext3 file system. Thus, if you wish to create an ext3 file system, use mkpart and create the file system with the mkfs command as described later. The changes start taking place as soon as you press Enter , so review the command before executing to it. After creating the partition, use the print command to confirm that it is in the partition table with the correct partition type, file system type, and size. Also remember the minor number of the new partition so that you can label any file systems on it. You should also view the output of cat /proc/partitions after parted is closed to make sure the kernel recognizes the new partition. The maximum number of partitions parted will create is 128. While the GUID Partition Table (GPT) specification allows for more partitions by growing the area reserved for the partition table, common practice used by parted is to limit it to enough area for 128 partitions.

Commands:
parted /dev/ sda
print
mkpart primary ext3 1024 2048
Chapter 6. References 6.1. Red Hat Configuring RHEL 8 for SAP HANA2 installation Configuring and managing high availability clusters on RHEL 8 Support Policies for RHEL High Availability Clusters Support Policies for RHEL High Availability Clusters - Fencing/STONITH Support Policies for RHEL High Availability Clusters - Management of SAP HANA in a Cluster Red Hat HA Solutions for SAP HANA, S/4HANA and NetWeaver based SAP Applications 6.2. SAP SAP HANA Server Installation and Update Guide SAP HANA System Replication Implementing a HA/DR Provider SAP Note 2057595 - FAQ: SAP HANA High Availability SAP Note 2063657 - SAP HANA System Replication Takeover Decision Guideline SAP Note 3007062 - FAQ: SAP HANA & Third Party Cluster Solutions 6.3. Other Be Prepared for Using Pacemaker Cluster for SAP HANA - Part 1: Basics Be Prepared for Using Pacemaker Cluster for SAP HANA - Part 2: Failure of Both Nodes

Commands:
11.4.2.4. Special Conditions and Actions Special characters used before Procmail recipe conditions and actions change the way they are interpreted. The following characters may be used after the * character at the beginning of a recipe's condition line: ! - In the condition line, this character inverts the condition, causing a match to occur only if the condition does not match the message. < - Checks if the message is under a specified number of bytes. > - Checks if the message is over a specified number of bytes. The following characters are used to perform special actions: ! - In the action line, this character tells Procmail to forward the message to the specified email addresses. USD - Refers to a variable set earlier in the rc file. This is often used to set a common mailbox that is referred to by various recipes. | - Starts a specified program to process the message. { and } - Constructs a nesting block, used to contain additional recipes to apply to matching messages. If no special character is used at the beginning of the action line, Procmail assumes that the action line is specifying the mailbox in which to write the message.

Commands:
Chapter 1. Introduction Migration Toolkit for Runtimes product will be End of Life on September 30th, 2024 All customers using this product should start their transition to Migration Toolkit for Applications . Migration Toolkit for Applications is fully backwards compatible with all features and rulesets available in Migration Toolkit for Runtimes and will be maintained in the long term. 1.1. About the MTR plugin for Eclipse You can migrate and modernize applications by using the Migration Toolkit for Runtimes (MTR) plugin for Eclipse. The MTR plugin analyzes your projects using customizable rulesets, marks issues in the source code, provides guidance to fix the issues, and offers automatic code replacement, if possible. 1.2. About the Migration Toolkit for Runtimes What is the Migration Toolkit for Runtimes? The Migration Toolkit for Runtimes (MTR) is an extensible and customizable rule-based tool that simplifies the migration and modernization of Java applications. MTR examines application artifacts, including project source directories and application archives, and then produces an HTML report highlighting areas needing changes. MTR supports many migration paths, including the following examples: Upgrading to the latest release of Red Hat JBoss Enterprise Application Platform Migrating from Oracle WebLogic or IBM WebSphere Application Server to Red Hat JBoss Enterprise Application Platform Containerizing applications and making them cloud-ready Migrating from Java Spring Boot to Quarkus Updating from Oracle JDK to OpenJDK Upgrading from OpenJDK 8 to OpenJDK 11 Upgrading from OpenJDK 11 to OpenJDK 17 Upgrading from OpenJDK 17 to OpenJDK 21 Migrating EAP Java applications to Azure Migrating Spring Boot Java applications to Azure For more information about use cases and migration paths, see the MTR for developers web page. How does the Migration Toolkit for Runtimes simplify migration? The Migration Toolkit for Runtimes looks for common resources and known trouble spots when migrating applications. It provides a high-level view of the technologies used by the application. MTR generates a detailed report evaluating a migration or modernization path. This report can help you to estimate the effort required for large-scale projects and to reduce the work involved. How do I learn more? See the Introduction to the Migration Toolkit for Runtimes to learn more about the features, supported configurations, system requirements, and available tools in the Migration Toolkit for Runtimes.

Commands:
4.247. python-psycopg2 4.247.1. RHBA-2012:0145 - python-psycopg2 bug fix and enhancement update An updated python-psycopg2 package that fixes multiple bugs and adds multiple enhancements is now available for Red Hat Enterprise Linux 6. The python-psycopg2 package provides a PostgreSQL database adapter for the Python programming language. The python-psycopg2 package has been upgraded to upstream version 2.0.14, which provides a number of bug fixes and enhancements over the version, including the fix for a memory leak in cursor handling. This update also ensures better compatibility with the PostgreSQL object-relational database management system version 8.4. (BZ# 787164 ) All users of python-psycopg2 are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
Chapter 1. Kafka tuning overview Fine-tuning the performance of your Kafka deployment involves optimizing various configuration properties according to your specific requirements. This section provides an introduction to common configuration options available for Kafka brokers, producers, and consumers. While a minimum set of configurations is necessary for Kafka to function, Kafka properties allow for extensive adjustments. Through configuration properties, you can enhance latency, throughput, and overall efficiency, ensuring that your Kafka deployment meets the demands of your applications. For effective tuning, take a methodical approach. Begin by analyzing relevant metrics to identify potential bottlenecks or areas for improvement. Adjust configuration parameters iteratively, monitoring the impact on performance metrics, and then refine your settings accordingly. For more information about Apache Kafka configuration properties, see the Apache Kafka documentation . Note The guidance provided here offers a starting point for tuning your Kafka deployment. Finding the optimal configuration depends on factors such as workload, infrastructure, and performance objectives. 1.1. Mapping properties and values How you specify configuration properties depends on the type of deployment. If you deployed Streams for Apache Kafka on OCP, you can use the Kafka resource to add configuration for Kafka brokers through the config property. With Streams for Apache Kafka on RHEL, you add the configuration to a properties file as environment variables. When you add config properties to custom resources, you use a colon (':') to map the property and value. Example configuration in a custom resource num.partitions:1 When you add the properties as environment variables, you use an equal sign ('=') to map the property and value. Example configuration as an environment variable num.partitions=1 Note Some examples in this guide may show resource configuration specifically for Streams for Apache Kafka on OpenShift. However, the properties presented are equally applicable as environment variables when using Streams for Apache Kafka on RHEL. 1.2. Tools that help with tuning The following tools help with Kafka tuning: Cruise Control generates optimization proposals that you can use to assess and implement a cluster rebalance Strimzi Quotas plugin sets limits on brokers Rack configuration spreads broker partitions across racks and allows consumers to fetch data from the nearest replica Additional resources For more information on these tools, see the following guides: Deploying and Managing Streams for Apache Kafka on OpenShift Using Streams for Apache Kafka on RHEL in KRaft mode Using Streams for Apache Kafka on RHEL with ZooKeeper

Commands:
num.partitions:1
num.partitions=1
2.9. Resource Management numad package The numad package provides a daemon for NUMA (Non-Uniform Memory Architecture) systems that monitors NUMA characteristics. As an alternative to manual static CPU pining and memory assignment, numad provides dynamic adjustment to minimize memory latency on an ongoing basis. The package also provides an interface that can be used to query the numad daemon for the best manual placement of an application. The numad package is introduced as a Technology Preview. Package: numad-0.5-4.20120522git

Commands:
1.2.4. Adding, Renaming, and Deleting Files Adding a File or Directory To add an existing file to a Subversion repository and put it under revision control, change to the directory with its working copy and run the following command: svn add file ... Similarly, to add a directory and all files that are in it, type: svn add directory ... This schedules the files and directories for addition to the Subversion repository. To proceed and actually add this content to the repository, run the svn commit command as described in Section 1.2.6, "Committing Changes" . Example 1.7. Adding a file to a Subversion repository Imagine that the directory with your working copy of a Subversion repository has the following contents: With the exception of ChangeLog , all files and directories within this directory are already under revision control. To schedule this file for addition to the Subversion repository, type: Renaming a File or Directory To rename an existing file or directory in a Subversion repository, change to the directory with its working copy and run the following command: svn move old_name new_name This creates a duplicate of the original file or directory, schedules it for addition, and automatically deletes the original. To proceed and actually rename the content in the Subversion repository, run the svn commit command as described in Section 1.2.6, "Committing Changes" . Example 1.8. Renaming a file in a Subversion repository Imagine that the directory with your working copy of a Subversion repository has the following contents: All files in this directory are under revision control. To schedule the LICENSE file for renaming to COPYING , type: Note that svn move automatically renames the file in your working copy: Deleting a File or Directory To remove a file from a Subversion repository, change to the directory with its working copy and run the following command: svn delete file ... Similarly, to remove a directory and all files that are in it, type: svn delete directory ... This schedules the files and directories for removal from the Subversion repository. To proceed and actually remove this content from the repository, run the svn commit command as described in Section 1.2.6, "Committing Changes" . Example 1.9. Deleting a file from a Subversion repository Imagine that the directory with your working copy of a Subversion repository has the following contents: All files in this directory are under revision control. To schedule the TODO file for removal from the SVN repository, type: Note that svn delete automatically deletes the file from your working copy:

Commands:
project]USD ls AUTHORS ChangeLog doc INSTALL LICENSE Makefile README src TODO
project]USD svn add ChangeLog A ChangeLog
project]USD ls AUTHORS ChangeLog doc INSTALL LICENSE Makefile README src TODO
project]USD svn move LICENSE COPYING A COPYING D LICENSE
project]USD ls AUTHORS ChangeLog COPYING doc INSTALL Makefile README src TODO
project]USD ls AUTHORS ChangeLog COPYING doc INSTALL Makefile README src TODO
project]USD svn delete TODO D TODO
project]USD ls AUTHORS ChangeLog COPYING doc INSTALL Makefile README src
Administration Guide Red Hat CodeReady Workspaces 2.15 Administering Red Hat CodeReady Workspaces 2.15 Robert Kratky rkratky@redhat.com Fabrice Flore-Thebault ffloreth@redhat.com Jana Vrbkova jvrbkova@redhat.com Max Leonov mleonov@redhat.com Red Hat Developer Group Documentation Team devtools-docs@redhat.com

Commands: