mtpti5iD/redhat-docs_dataset huggingface dataset:
4.121. keyutils 4.121.1. RHEA-2011:1684 - keyutils bug fix and enhancement update Updated keyutils packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. The keyutils package provides utilities to control the Linux kernel key management facility and to provide a mechanism by which the kernel calls up to user space to get a key instantiated. Bug Fix BZ# 730002 The keyutils subpackage did not contain a dependency on the keyutils-libs subpackage but rather it contained only an implicit dependency on the libkeyutils.so.[n] shared object files specified as the SONAME variable. As a consequence, the keyutils subpackage could have been updated without applying the newest keyutils libraries, which could have caused keyutils to work incorrectly. To fix this issue, the keyutils spec file has been modified to include an explicit dependency on the version of keyutils-libs that matches the keyutils subpackage. Both subpackages are now updated together. Enhancement BZ# 727280 Previously, the keyutils subpackages were compiled without the RELRO (read-only relocations) flag. Programs provided by this package and also programs built against the keyutils libraries were thus vulnerable to various attacks based on overwriting the ELF section of a program. To increase the security of keyutils programs and libraries, the keyutils spec file has been modified to use the "-Wl,-z,relro" flags when compiling the packages. As a result, the keyutils subpackages are now provided with partial RELRO protection. Users are advised to upgrade to these updated keyutils packages, which fix this bug and add this enhancement.

Commands:
Chapter 5. Red Hat build of OpenJDK MSI installer components You can set the following Red Hat build of OpenJDK 21 for Microsoft Windows MSI-based installer components. Setting these components is optional. If these components are not set, the default settings will be used. jdk Java Development Kit (JDK) files. Defaults to true , meaning that the jdk component is enabled. jdk_registry_runtime A set of Windows registry keys that other software can use to locate JDK installation files. Defaults to true , meaning that the jdk_registry_runtime component is enabled. This component includes the following registry keys: jdk_env_path Appends <INSTALLDIR>\bin to the system %PATH% environment variable. jdk_env_java_home Sets <INSTALLDIR> to the system %JAVA_HOME% environment variable. jdk_env_vendor_java_home Sets <INSTALLDIR> to the system %REDHAT_JAVA_HOME% environment variable. jdk_registry_jar Association for JAR files. Launch JAR files with the Red Hat build of OpenJDK context menu. jmc JDK Mission Control files, installed into <INSTALLDIR>\missioncontrol . jmc_env Appends <INSTALLDIR>\missioncontrol to the system %PATH% environment variable.

Commands:
HKLM\Software\JavaSoft\JDK\<version>, entries: JavaHome: <INSTALLDIR> RuntimeLib: <INSTALLDIR>\bin\server\jvm.dll HKLM\Software\JavaSoft\JDK, entries: CurrentVersion: <version>
3.5.6. Using Arrays in Conditional Statements You can also use associative arrays in if statements. This is useful if you want to execute a subroutine once a value in the array matches a certain condition. Consider the following example: Example 3.17. vfsreads-print-if-1kb.stp Every three seconds, Example 3.17, "vfsreads-print-if-1kb.stp" prints out a list of all processes, along with how many times each process performed a VFS read. If the associated value of a process name is equal or greater than 1024, the if statement in the script converts and prints it out in kB . Testing for Membership You can also test whether a specific unique key is a member of an array. Further, membership in an array can be used in if statements, as in: To illustrate this, consider the following example: Example 3.18. vfsreads-stop-on-stapio2.stp The if(["stapio"] in reads) statement instructs the script to print stapio read detected, exiting once the unique key stapio is added to the array reads .

Commands:
global reads probe vfs.read { reads[execname()] ++ } probe timer.s(3) { printf("=======\n") foreach (count in reads-) if (reads[count] >= 1024) printf("%s : %dkB \n", count, reads[count]/1024) else printf("%s : %dB \n", count, reads[count]) }
if([ index_expression ] in array_name ) statement
global reads probe vfs.read { reads[execname()] ++ } probe timer.s(3) { printf("=======\n") foreach (count in reads+) printf("%s : %d \n", count, reads[count]) if(["stapio"] in reads) { printf("stapio read detected, exiting\n") exit() } }
5.4. Using the sysctl Command The /sbin/sysctl command is used to view, set, and automate kernel settings in the /proc/sys/ directory. For a quick overview of all settings configurable in the /proc/sys/ directory, type the /sbin/sysctl -a command as root. This creates a large, comprehensive list, a small portion of which looks something like the following: This is the same information seen if each of the files were viewed individually. The only difference is the file location. For example, the /proc/sys/net/ipv4/route/min_delay file is listed as net.ipv4.route.min_delay , with the directory slashes replaced by dots and the proc.sys portion assumed. The sysctl command can be used in place of echo to assign values to writable files in the /proc/sys/ directory. For example, instead of using the command use the equivalent sysctl command as follows: While quickly setting single values like this in /proc/sys/ is helpful during testing, this method does not work as well on a production system as special settings within /proc/sys/ are lost when the machine is rebooted. To preserve custom settings, add them to the /etc/sysctl.conf file. Each time the system boots, the init program runs the /etc/rc.d/rc.sysinit script. This script contains a command to execute sysctl using /etc/sysctl.conf to determine the values passed to the kernel. Any values added to /etc/sysctl.conf therefore take effect each time the system boots.

Commands:
net.ipv4.route.min_delay = 2 kernel.sysrq = 0 kernel.sem = 250 32000 32 128
echo 1 > /proc/sys/kernel/sysrq
sysctl -w kernel.sysrq="1" kernel.sysrq = 1
Chapter 2. What is deployed with AMQ Streams Apache Kafka components are provided for deployment to OpenShift with the AMQ Streams distribution. The Kafka components are generally run as clusters for availability. A typical deployment incorporating Kafka components might include: Kafka cluster of broker nodes ZooKeeper cluster of replicated ZooKeeper instances Kafka Connect cluster for external data connections Kafka MirrorMaker cluster to mirror the Kafka cluster in a secondary cluster Kafka Exporter to extract additional Kafka metrics data for monitoring Kafka Bridge to make HTTP-based requests to the Kafka cluster Not all of these components are mandatory, though you need Kafka and ZooKeeper as a minimum. Some components can be deployed without Kafka, such as MirrorMaker or Kafka Connect. 2.1. Order of deployment The required order of deployment to an OpenShift cluster is as follows: Deploy the Cluster Operator to manage your Kafka cluster Deploy the Kafka cluster with the ZooKeeper cluster, and include the Topic Operator and User Operator in the deployment Optionally deploy: The Topic Operator and User Operator standalone if you did not deploy them with the Kafka cluster Kafka Connect Kafka MirrorMaker Kafka Bridge Components for the monitoring of metrics 2.2. Additional deployment configuration options The deployment procedures in this guide describe a deployment using the example installation YAML files provided with AMQ Streams. The procedures highlight any important configuration considerations, but they do not describe all the configuration options available. You can use custom resources to refine your deployment. You may wish to review the configuration options available for Kafka components before you deploy AMQ Streams. For more information on the configuration through custom resources, see Deployment configuration in the Using AMQ Streams on OpenShift guide. 2.2.1. Securing Kafka On deployment, the Cluster Operator automatically sets up TLS certificates for data encryption and authentication within your cluster. AMQ Streams provides additional configuration options for encryption , authentication and authorization , which are described in the Using AMQ Streams on OpenShift guide: Secure data exchange between the Kafka cluster and clients by Managing secure access to Kafka . Configure your deployment to use an authorization server to provide OAuth 2.0 authentication and OAuth 2.0 authorization . Secure Kafka using your own certificates . 2.2.2. Monitoring your deployment AMQ Streams supports additional deployment options to monitor your deployment. Extract metrics and monitor Kafka components by deploying Prometheus and Grafana with your Kafka cluster . Extract additional metrics, particularly related to monitoring consumer lag, by deploying Kafka Exporter with your Kafka cluster . Track messages end-to-end by setting up distributed tracing , as described in the Using AMQ Streams on OpenShift guide.

Commands:
Chapter 1. Introduction to Red Hat Enterprise Linux for SAP Solutions Red Hat Enterprise Linux for SAP Solutions is a SAP specific offering, tailored to the needs of SAP workloads such as SAP NetWeaver, SAP S/4HANA and SAP HANA platform. 1.1. Red Hat Enterprise Linux for SAP Solutions Built on the foundation of Red Hat Enterprise Linux with its packages and components, in addition to this foundation, the RHEL for SAP Solutions subscription includes the following: SAP-specific technical components to support SAP S/4HANA, SAP HANA, and SAP Business Applications. SAP-specific High Availability solutions for SAP S/4HANA, SAP HANA, and SAP Business Applications. RHEL System Roles for SAP for automation of operating system configuration to run SAP workloads. SAP tailored Red Hat Insights Dashboard and Smart Management helps streamline operations and to reduce costs Update Services for SAP Solutions (E4S) or Extended Update Support (EUS), providing support for specific minor RHEL releases for up to four years from General Availability. See the RHEL Life Cycle web page for more information about EUS and Update Services for SAP Solutions. Note Update Services for SAP Solutions (E4S) is only provided with RHEL for SAP Solutions. It is not available on any other RHEL products. Update Services for SAP Solutions (E4S) is only provided on specified minor RHEL releases, which may be different from the EUS releases.

Commands:
Part IV. Installing and configuring Red Hat Process Automation Manager on Red Hat JBoss Web Server This document describes how to install Red Hat Process Automation Manager 7.13 on JBoss Web Server. Note Support for Red Hat Process Automation Manager on Red Hat JBoss Web Server and Apache Tomcat is now in the maintenance phase. Red Hat will continue to support Red Hat Process Automation Manager on these platforms with the following limitations: Red Hat will not release new certifications or software functionality. Red Hat will release only qualified security patches that have a critical impact and mission-critical bug fix patches. In the future, Red Hat might direct customers to migrate to new platforms and product components that are compatible with the Red Hat hybrid cloud strategy. Prerequisites You have reviewed the information in Planning a Red Hat Process Automation Manager installation . You have installed Red Hat JBoss Web Server 5.5.1. For information about installing Red Hat JBoss Web Server, see the Red Hat JBoss Web Server Installation Guide .

Commands:
Chapter 3. Organizations, Locations, and Repositories Table 3.1. Organizations, Locations, and Repositories Subcommand Description and tasks organization Create an organization: List organizations: location See the options for organization subscription org Upload a subscription manifest: repository-set org Enable a repository: repository org Synchronize a repository: Create a custom repository: Upload content to a custom repository:

Commands:
hammer organization create --name org_name
hammer organization list
hammer subscription upload --file path
hammer repository-set enable --product prod_name --basearch base_arch --releasever rel_v --name repo_name
hammer repository synchronize --product prod_name --name repo_name
hammer repository create --product prod_name --content-type cont_type --publish-via-http true --url repo_url --name repo_name
hammer repository upload-content --product prod_name --id repo_id --path path_to_dir
Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. To propose improvements, open a Jira issue and describe your suggested changes. Provide as much detail as possible to enable us to address your request quickly. Prerequisite You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one. Procedure Click the following Create issue . In the Summary text box, enter a brief description of the issue. In the Description text box, provide the following information: The URL of the page where you found the issue. A detailed description of the issue. You can leave the information in any other fields at their default values. Click Create to submit the Jira issue to the documentation team. Thank you for taking the time to provide feedback. Administering the API Gateway helps you to apply intermediate to advanced configuration features to your 3scale installation. For basic details regarding installation, refer to Installing 3scale.

Commands:
Chapter 1. Introduction to developing applications with Camel Extensions for Quarkus This guide is for developers writing Camel applications on top of Camel Extensions for Quarkus. Camel components which are supported in Camel Extensions for Quarkus have an associated Camel Extensions for Quarkus extension. For more information about the Camel Extensions for Quarkus extensions supported in this distribution, see the Camel Extensions for Quarkus Reference reference guide.

Commands:
Chapter 2. Red Hat Ansible Automation Platform Architecture As a modular platform, Ansible Automation Platform provides the flexibility to easily integrate components and customize your deployment to best meet your automation requirements. This section provides a comprehensive architectural example of an Ansible Automation Platform deployment. 2.1. Example Ansible Automation Platform architecture The Red Hat Ansible Automation Platform 2.3 reference architecture provides an example setup of a standard deployment of Ansible Automation Platform using automation mesh on Red Hat Enterprise Linux. The deployment shown takes advantage of the following key components to provide a simple, secure and flexible method of handling your automation workloads, a central location for content collections, and automated resolution of IT requests. Automation controller Provides the control plane for automation through its UI, Restful API, RBAC workflows and CI/CD integrations. Automation mesh Is an overlay network that provides the ability to ease the distribution of work across a large and dispersed collection of workers through nodes that establish peer-to-peer connections with each other using existing networks. Private automation hub Provides automation developers the ability to collaborate and publish their own automation content and streamline delivery of Ansible code within their organization. The architecture for this example consists of the following: A two node automation controller cluster An optional hop node to connect automation controller to execution nodes A two node automation hub cluster A single PostgreSQL database connected to the automation controller and automation hub Two execution nodes per automation controller cluster Figure 2.1. Example Ansible Automation Platform 2.3 architecture

Commands:
14.17. Configuring the Guest Virtual Machine CPU Model For simple defaults, the guest virtual machine CPU configuration accepts the same basic XML representation as the host physical machine capabilities XML exposes. In other words, the XML from the cpu-baseline virsh command can now be copied directly into the guest virtual machine XML at the top level under the <domain> element. In the XML snippet, there are a few extra attributes available when describing a CPU in the guest virtual machine XML. These can mostly be ignored, but for the curious here is a quick description of what they do. The top level <cpu> element has an attribute called match with possible values of: match='minimum' - the host physical machine CPU must have at least the CPU features described in the guest virtual machine XML. If the host physical machine has additional features beyond the guest virtual machine configuration, these will also be exposed to the guest virtual machine. match='exact' - the host physical machine CPU must have at least the CPU features described in the guest virtual machine XML. If the host physical machine has additional features beyond the guest virtual machine configuration, these will be masked out from the guest virtual machine. match='strict' - the host physical machine CPU must have exactly the same CPU features described in the guest virtual machine XML. The enhancement is that the <feature> elements can each have an extra 'policy' attribute with possible values of: policy='force' - expose the feature to the guest virtual machine even if the host physical machine does not have it. This is usually only useful in the case of software emulation. policy='require' - expose the feature to the guest virtual machine and fail if the host physical machine does not have it. This is the sensible default. policy='optional' - expose the feature to the guest virtual machine if it happens to support it. policy='disable' - if the host physical machine has this feature, then hide it from the guest virtual machine. policy='forbid' - if the host physical machine has this feature, then fail and refuse to start the guest virtual machine. The 'forbid' policy is for a niche scenario where an incorrectly functioning application will try to use a feature even if it is not in the CPUID mask, and you wish to prevent accidentally running the guest virtual machine on a host physical machine with that feature. The 'optional' policy has special behavior with respect to migration. When the guest virtual machine is initially started the parameter is optional, but when the guest virtual machine is live migrated, this policy turns into 'require', since you cannot have features disappearing across migration.

Commands:
Chapter 6. Configuring the heap size for Red Hat build of OpenJDK application on RHEL You can configure Red Hat build of OpenJDK to use a customized heap size. Procedure Add the maximum heap size option to the java command when running your application. For example, to set the maximum heap size to 100 megabytes, use the -Xmx100m option: Additional resources For more information about the Xmx option, see -Xmxsize in the Java documentation .

Commands:
java -Xmx100m <your_application_name>
7.116. lsof 7.116.1. RHBA-2015:1246 - lsof bug fix update Updated lsof packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The lsof (LiSt Open Files) package provides a utility to list information about files that are open by the processes running on Linux and UNIX systems. Bug Fixes BZ# 772991 Prior to this update, the lsof utility could, under certain circumstances, report incorrect server locations of mounted folders if multiple Network File System (NFS) shares from one host were mounted. This update allows multiple NFS clients to share superblocks. Now, lsof reports the correct server locations of mounted folders. BZ# 668099 Previously, lsof did not recognize Stream Control Transmission Protocol (SCTP) associations and consequently printed "can't identify protocol" at the end of the line describing a process using this type of association. With this update, support for SCTP has been added, and as a result, lsof correctly identifies SCTP associations in its output. Users of lsof are advised to upgrade to these updated packages, which fix these bugs.

Commands:
5.276. readline 5.276.1. RHBA-2012:0834 - readline bug fix and enhancement update Updated readline packages that fix a bug and add an enhancement are now available for Red Hat Enterprise Linux 6. The Readline library provides a set of functions that allow users to edit command lines. Bug Fix BZ# 722942 Previously, the Readline library defined isxdigit as a macro but it is a template function in C++. Consequently, when compiling C++ code, every other C++ header had to be included before the Readline headers in order to avoid compiling errors. With this update, isxdigit is no longer defined as a macro if the compiled program is in C++. As a result, developers no longer have to avoid including Readline headers first when working with C++. Enhancement BZ# 244350 This update adds advisory TTY input audit events, to record the lines actually reported to applications. Users are advised to upgrade to these updated readline packages, which fix this bug and add this enhancement.

Commands:
5.4.16.11. Controlling I/O Operations on a RAID1 Logical Volume As of the Red Hat Enterprise Linux release 6.5, you can control the I/O operations for a device in a RAID1 logical volume by using the --writemostly and --writebehind parameters of the lvchange command. The format for using these parameters is as follows. --[raid]writemostly PhysicalVolume [:{t|y|n}] Marks a device in a RAID1 logical volume as write-mostly . All reads to these drives will be avoided unless necessary. Setting this parameter keeps the number of I/O operations to the drive to a minimum. The default behavior is to set the write-mostly attribute for the specified physical volume in the logical volume. It is possible to remove the write-mostly flag by appending :n to the physical volume or to toggle the value by specifying :t . The --writemostly argument can be specified more than one time in a single command, making it possible to toggle the write-mostly attributes for all the physical volumes in a logical volume at once. --[raid]writebehind IOCount Specifies the maximum number of outstanding writes that are allowed to devices in a RAID1 logical volume that are marked as write-mostly . Once this value is exceeded, writes become synchronous, causing all writes to the constituent devices to complete before the array signals the write has completed. Setting the value to zero clears the preference and allows the system to choose the value arbitrarily.

Commands:
4.236. powertop 4.236.1. RHBA-2011:1230 - powertop bug fix update An updated powertop package that fixes one bug is now available for Red Hat Enterprise Linux 6. PowerTOP is a tool to detect all the software components that make a computer consume more than necessary power when idle. PowerTOP can be used to reduce power usage by running various commands on the system. Bug Fix BZ# 698422 Previously, PowerTOP did not correctly handle the SIGWINCH signal. As a result, PowerTOP was terminated unexpectedly if the terminal window, in which PowerTOP was running, was resized. This update fixes the SIGWINCH signal handling so that PowerTOP is not unexpectedly terminated if the terminal window is resized. All PowerTOP users are advised to upgrade to this updated package, which fixes this bug.

Commands: