mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Component details The following table shows the component versions for each AMQ Streams release. AMQ Streams Apache Kafka Strimzi Operators Kafka Bridge Oauth Cruise Control 2.5.2 3.5.0 (+ 3.5.2) 0.36.0 0.26 0.13.0 2.5.123 2.5.1 3.5.0 0.36.0 0.26 0.13.0 2.5.123 2.5.0 3.5.0 0.36.0 0.26 0.13.0 2.5.123 2.4.0 3.4.0 0.34.0 0.25.0 0.12.0 2.5.112 2.3.0 3.3.1 0.32.0 0.22.3 0.11.0 2.5.103 2.2.2 3.2.3 0.29.0 0.21.5 0.10.0 2.5.103 2.2.1 3.2.3 0.29.0 0.21.5 0.10.0 2.5.103 2.2.0 3.2.3 0.29.0 0.21.5 0.10.0 2.5.89 2.1.0 3.1.0 0.28.0 0.21.4 0.10.0 2.5.82 2.0.1 3.0.0 0.26.0 0.20.3 0.9.0 2.5.73 2.0.0 3.0.0 0.26.0 0.20.3 0.9.0 2.5.73 1.8.4 2.8.0 0.24.0 0.20.1 0.8.1 2.5.59 1.8.0 2.8.0 0.24.0 0.20.1 0.8.1 2.5.59 1.7.0 2.7.0 0.22.1 0.19.0 0.7.1 2.5.37 1.6.7 2.6.3 0.20.1 0.19.0 0.6.1 2.5.11 1.6.6 2.6.3 0.20.1 0.19.0 0.6.1 2.5.11 1.6.5 2.6.2 0.20.1 0.19.0 0.6.1 2.5.11 1.6.4 2.6.2 0.20.1 0.19.0 0.6.1 2.5.11 1.6.0 2.6.0 0.20.0 0.19.0 0.6.1 2.5.11 1.5.0 2.5.0 0.18.0 0.16.0 0.5.0 - 1.4.1 2.4.0 0.17.0 0.15.2 0.3.0 - 1.4.0 2.4.0 0.17.0 0.15.2 0.3.0 - 1.3.0 2.3.0 0.14.0 0.14.0 0.1.0 - 1.2.0 2.2.1 0.12.1 0.12.2 - - 1.1.1 2.1.1 0.11.4 - - - 1.1.0 2.1.1 0.11.1 - - - 1.0 2.0.0 0.8.1 - - - Note Strimzi 0.26.0 contains a Log4j vulnerability. The version included in the product has been updated to depend on versions that do not contain the vulnerability.

Commands:
Chapter 1. Overview AMQ Broker is a high-performance messaging implementation based on ActiveMQ Artemis. It has fast, journal-based message persistence and supports multiple languages, protocols, and platforms. AMQ Broker provides multiple interfaces for managing and interacting with your broker instances, such as a management console, management APIs, and a command-line interface. In addition, you can monitor broker performance by collecting runtime metrics, configure brokers to proactively monitor for problems such as deadlock conditions, and interactively check the health of brokers and queues. This guide provides detailed information about typical broker management tasks such as: Upgrading your broker instances Using the command-line interface and management API Checking the health of brokers and queues Collecting broker runtime metrics Proactively monitoring critical broker operations 1.1. Supported configurations Refer to the article " Red Hat AMQ 7 Supported Configurations " on the Red Hat Customer Portal for current information regarding AMQ Broker supported configurations. 1.2. Document conventions This document uses the following conventions for the sudo command, file paths, and replaceable values. The sudo command In this document, sudo is used for any command that requires root privileges. You should always exercise caution when using sudo , as any changes can affect the entire system. For more information about using sudo , see The sudo Command . About the use of file paths in this document In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/... ). If you are using Microsoft Windows, you should use the equivalent Microsoft Windows paths (for example, C:\Users\... ). Replaceable values This document sometimes uses replaceable values that you must replace with values specific to your environment. Replaceable values are lowercase, enclosed by angle brackets ( < > ), and are styled using italics and monospace font. Multiple words are separated by underscores ( _ ) . For example, in the following command, replace <install_dir> with your own directory name. USD <install_dir> /bin/artemis create mybroker

Commands:
<install_dir> /bin/artemis create mybroker
5.92. gnome-settings-daemon 5.92.1. RHBA-2012:1450 - gnome-settings-daemon bug fix update Updated gnome-settings-daemon packages that fix a bug is now available for Red Hat Enterprise Linux 6. The gnome-settings-daemon packages contain a daemon to share settings from GNOME with other applications. It also handles global key bindings, as well as a number of desktop-wide settings. Bug Fix BZ# 866528 Previously, when a system hotkey was used to change the display configuration, sometimes a valid XRandR configuration failed to be selected and the monitors were not kept in clone mode. Consequently, it was impossible to switch displays. With this update, gnome-settings-daemon always selects valid XRandR modes, and sets or unsets clone mode as expected, thus fixing this bug. Users of gnome-settings-daemon are advised to upgrade to these updated packages, which fix this bug. 5.92.2. RHBA-2012:0949 - gnome-settings-daemon bug fix and enhancement update An updated gnome-settings-daemon package that fixes several bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The gnome-settings-daemon package contains a daemon to share settings from GNOME with other applications. It also handles global key bindings, as well as a number of desktop-wide settings. Bug Fixes BZ# 693843 Previously, the selected keyboard layout on certain machines reverted to the "US" layout every time the user logged in. With this update, the bug has been fixed so that the selected keyboard layout is not reverted anymore. BZ# 805036 Previously, the automatic mapping of the screen tablet did not work with the NVIDIA driver. With this update, support for the NV-CONTROL extension has been added so that the automatic mapping of the screen tablet now works as expected. BZ# 805042 Previously, the button mapping to actions did not work in the Wacom graphics tablet plug-in. As a result, the Map Buttons did not display in the GUI and activating buttons on the Wacom graphics tablet had no effect. With this update, these problems have been fixed. Enhancements BZ# 769464 With this update, Wacom graphics tablets are now supported with gnome-settings-daemon. BZ# 816646 This update modifies the way gnome-settings-daemon stores settings in GConf. Previously, the settings were stored per user and per device. With this update, the settings are now stored per user, per device, and per machine. All users of gnome-settings-daemon are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
Chapter 1. Introduction to Red Hat Quay OAuth 2.0 tokens The Red Hat Quay OAuth 2 token system provides a secure, standards-based method for accessing Red Hat Quay's API and other relevant resources. The OAuth 2 token-based approach provides a secure method for handling authentication and authorization for complex environments. Compared to more traditional API tokens, Red Hat Quay's OAuth 2 token system offers the following enhancements: Standards-based security, which adheres to the OAuth 2.0 protocol . Revocable access by way of deleting the application in which the OAuth 2 token exists. Fine-grained access control, which allows Red Hat Quay administrators the ability to assign specific permissions to tokens. Delegated access, which allows third-party applications and services to act on behalf of a user. Future-proofing, which helps ensure that Red Hat Quay remains compatible with other services, platforms, and integrations. Red Hat Quay primarily supports two types of tokens: OAuth 2 access tokens and robot account tokens. A third token type, an OCI referrers access token , that is required to list OCI referrers of a manifest under a repository, is also available when warranted. The following chapters provide more details about each token type and how to generate each token type.

Commands:
Chapter 8. Email Templates By the end of this section, you will have edited and saved a custom email template. You can completely customize the content of all standard email communication with developers, allowing you to closely match the workflows you have set up for your Developer Portal. 8.1. Customizing email templates 8.1.1. Define your workflows before email configuration There are a lot of email template options, only a subset of which will be relevant for your workflows. Save yourself time by making sure you're happy with your workflows before beginning to edit the email templates. This way, you'll only edit the templates that you'll actually use. 8.1.2. Test your workflow and identify active email templates Perform a dry run of your finalized workflows, making sure to test all the possible branches, such as approval and rejection. Then, identify each email notification that your test developer account receives to determine what to edit in the step. 8.1.3. Edit and save your custom template The first time you edit a template, you will actually create a custom template. Then in subsequent edits, you will save your changes. Warning There is no version control. Red Hat recommends you make a local copy if you want to be able to revert changes. You can use liquid tags for dynamic content in your email. We especially recommend you make backups when you make changes to the liquid tags. 8.1.4. Repeat for all templates in your workflows Complete these same steps until you've covered all possible branches for your workflows. 8.2. More information Before customizing your email templates, it is best to have the signup flows fully finalized and tested. If you intend to change any of the liquid tags within the email templates, be sure to read up on the liquid reference documentation .

Commands:
1.2. Overview of DM Multipath DM Multipath can be used to provide: Redundancy DM Multipath can provide failover in an active/passive configuration. In an active/passive configuration, only half the paths are used at any time for I/O. If any element of an I/O path (the cable, switch, or controller) fails, DM Multipath switches to an alternate path. Improved Performance DM Multipath can be configured in active/active mode, where I/O is spread over the paths in a round-robin fashion. In some configurations, DM Multipath can detect loading on the I/O paths and dynamically rebalance the load. Figure 1.1, "Active/Passive Multipath Configuration with One RAID Device" shows an active/passive configuration with two I/O paths from the server to a RAID device. There are 2 HBAs on the server, 2 SAN switches, and 2 RAID controllers. Figure 1.1. Active/Passive Multipath Configuration with One RAID Device In this configuration, there is one I/O path that goes through hba1, SAN1, and controller 1 and a second I/O path that goes through hba2, SAN2, and controller2. There are many points of possible failure in this configuration: HBA failure FC cable failure SAN switch failure Array controller port failure With DM Multipath configured, a failure at any of these points will cause DM Multipath to switch to the alternate I/O path. Figure 1.2, "Active/Passive Multipath Configuration with Two RAID Devices" shows a more complex active/passive configuration with 2 HBAs on the server, 2 SAN switches, and 2 RAID devices with 2 RAID controllers each. Figure 1.2. Active/Passive Multipath Configuration with Two RAID Devices In the example shown in Figure 1.2, "Active/Passive Multipath Configuration with Two RAID Devices" , there are two I/O paths to each RAID device (just as there are in the example shown in Figure 1.1, "Active/Passive Multipath Configuration with One RAID Device" ). With DM Multipath configured, a failure at any of the points of the I/O path to either of the RAID devices will cause DM Multipath to switch to the alternate I/O path for that device. Figure 1.3, "Active/Active Multipath Configuration with One RAID Device" shows an active/active configuration with 2 HBAs on the server, 1 SAN switch, and 2 RAID controllers. There are four I/O paths from the server to a storage device: hba1 to controller1 hba1 to controller2 hba2 to controller1 hba2 to controller2 In this configuration, I/O can be spread among those four paths. Figure 1.3. Active/Active Multipath Configuration with One RAID Device

Commands:
Chapter 1. Cluster health 1.1. Verifying OpenShift Data Foundation is healthy Storage health is visible on the Block and File and Object dashboards. Procedure In the OpenShift Web Console, click Storage OpenShift Data Foundation . In the Status card of the Overview tab, click Storage System and then click the storage system link from the pop up that appears. Check if the Status card has a green tick in the Block and File and the Object tabs. Green tick indicates that the cluster is healthy. See Section 1.2, "Storage health levels and cluster state" for information about the different health states and the alerts that appear. 1.2. Storage health levels and cluster state Status information and alerts related to OpenShift Data Foundation are displayed in the storage dashboards. 1.2.1. Block and File dashboard indicators The Block and File dashboard shows the complete state of OpenShift Data Foundation and the state of persistent volumes. The states that are possible for each resource type are listed in the following table. Table 1.1. OpenShift Data Foundation health levels State Icon Description UNKNOWN OpenShift Data Foundation is not deployed or unavailable. Green Tick Cluster health is good. Warning OpenShift Data Foundation cluster is in a warning state. In internal mode, an alert will be displayed along with the issue details. Alerts are not displayed for external mode. Error OpenShift Data Foundation cluster has encountered an error and some component is nonfunctional. In internal mode, an alert is displayed along with the issue details. Alerts are not displayed for external mode. 1.2.2. Object dashboard indicators The Object dashboard shows the state of the Multicloud Object Gateway and any object claims in the cluster. The states that are possible for each resource type are listed in the following table. Table 1.2. Object Service health levels State Description Green Tick Object storage is healthy. Multicloud Object Gateway is not running Shown when NooBaa system is not found. All resources are unhealthy Shown when all NooBaa pools are unhealthy. Many buckets have issues Shown when >= 50% of buckets encounter error(s). Some buckets have issues Shown when >= 30% of buckets encounter error(s). Unavailable Shown when network issues and/or errors exist. 1.2.3. Alert panel The Alert panel appears below the Status card in both the Block and File dashboard and the Object dashboard when the cluster state is not healthy. Information about specific alerts and how to respond to them is available in Troubleshooting OpenShift Data Foundation .

Commands:
2.3.6. Removing Fence Methods and Fence Instances To remove a fence method from your cluster configuration, execute the following command: For example, to remove a fence method that you have named APC that you have configured for node01.example.com from the cluster configuration file on cluster node node01.example.com , execute the following command: To remove all fence instances of a fence device from a fence method, execute the following command: For example, to remove all instances of the fence device named apc1 from the method named APC-dual configured for node01.example.com from the cluster configuration file on cluster node node01.example.com , execute the following command:

Commands:
ccs -h host --rmmethod method node
ccs -h node01.example.com --rmmethod APC node01.example.com
ccs -h host --rmfenceinst fencedevicename node method
ccs -h node01.example.com --rmfenceinst apc1 node01.example.com APC-dual
Chapter 2. Support Requirements This chapter outlines the requirements for creating a supported integration of Red Hat Gluster Storage and Red Hat Virtualization. 2.1. Prerequisites Integrating Red Hat Gluster Storage with Red Hat Virtualization has the following requirements: All installations of Red Hat Virtualization and Red Hat Gluster Storage must have valid subscriptions to Red Hat Network channels and Subscription Management repositories. Red Hat Virtualization installations must adhere to the requirements laid out in the Red Hat Virtualization Installation Guide : https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html-single/installing_red_hat_virtualization_as_a_self-hosted_engine_using_the_cockpit_web_interface/index#RHV_requirements . Red Hat Gluster Storage installations must adhere to the requirements laid out in the Red Hat Gluster Storage Installation Guide : https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/installation_guide/chap-planning_red_hat_storage_installation . Red Hat Gluster Storage installations must be completely up to date with the latest patches and upgrades. Refer to the Red Hat Gluster Storage 3.5 Installation Guide to upgrade to the latest version: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/installation_guide/ . The versions of Red Hat Virtualization and Red Hat Gluster Storage integrated must be compatible, according to the table in Section 2.2, "Compatible Versions" . A fully-qualified domain name must be set for each hypervisor and Red Hat Gluster Storage server node. Ensure that correct DNS records exist, and that the fully-qualified domain name is resolvable via both forward and reverse DNS lookup. Red Hat Gluster Storage volumes must either use three-way replication or arbitrated replication. This reduces the risk of split-brain condition developing in the cluster. The following volume types are supported: three-way replicated and distributed replicated volumes ( replica count 3 ) arbitrated replicated or distributed arbitrated replicated volumes ( replica 3 arbiter 1 ) Server-side quorum, client-side quorum, and sharding are all required for a supported configuration. These are enabled by default in the virt tuning profile covered in Chapter 4, Hosting Virtual Machine Images on Red Hat Gluster Storage volumes . See Preventing Split-brain for information about how quorum settings help prevent split brain. See Creating Sharded Volumes for information about why sharding reduces heal and geo-replication time.

Commands:
Chapter 5. Backing OpenShift Container Platform applications with OpenShift Container Storage You cannot directly install OpenShift Container Storage during the OpenShift Container Platform installation. However, you can install OpenShift Container Storage on an existing OpenShift Container Platform by using the Operator Hub and then configure the OpenShift Container Platform applications to be backed by OpenShift Container Storage. Prerequisites OpenShift Container Platform is installed and you have administrative access to OpenShift Web Console. OpenShift Container Storage is installed and running in the openshift-storage namespace. Procedure In the OpenShift Web Console, perform one of the following: Click Workloads Deployments . In the Deployments page, you can do one of the following: Select any existing deployment and click Add Storage option from the Action menu (...). Create a new deployment and then add storage. Click Create Deployment to create a new deployment. Edit the YAML based on your requirement to create a deployment. Click Create . Select Add Storage from the Actions drop down menu on the top right of the page. Click Workloads Deployment Configs . In the Deployment Configs page, you can do one of the following: Select any existing deployment and click Add Storage option from the Action menu (...). Create a new deployment and then add storage. Click Create Deployment Config to create a new deployment. Edit the YAML based on your requirement to create a deployment. Click Create . Select Add Storage from the Actions drop down menu on the top right of the page. In the Add Storage page, you can choose one of the following options: Click the Use existing claim option and select a suitable PVC from the drop down list. Click the Create new claim option. Select the appropriate CephFS or RBD storage class from the Storage Class drop down list. Provide a name for the Persistent Volume Claim. Select ReadWriteOnce (RWO) or ReadWriteMany (RWX) access mode. Note ReadOnlyMany (ROX) is deactivated as it is not supported. Select the size of the desired storage capacity. Note You can expand block PVs but cannot reduce the storage capacity after the creation of Persistent Volume Claim. Specify the mount path and subpath (if required) for the mount path volume inside the container. Click Save . Verification steps Depending on your configuration, perform one of the following: Click Workloads Deployments . Click Workloads Deployment Configs . Set the Project as required. Click the deployment for which you added storage to view the deployment details. Scroll down to Volumes and verify that your deployment has a Type that matches the Persistent Volume Claim that you assigned. Click the Persistent Volume Claim name and verify the storage class name in the Persistent Volume Claim Overview page.

Commands:
13.17. Kdump Use this screen to select whether or not to use Kdump on this system. Kdump is a kernel crash dumping mechanism which, in the event of a system crash, captures information that can be invaluable in determining the cause of the crash. Note that if you enable Kdump , you must reserve a certain amount of system memory for it. As a result, less memory is available for your processes. IBM Power System LPARs support firmware-assisted dump ( fadump ), an alternate dump capture mechanism to Kdump . With fadump , dump capture takes place from a fully reset system that is loaded with a fresh copy of the kernel. In particular, PCI and I/O devices are reinitialized and are in a clean, consistent state making it a reliable alternative to Kdump . Note that although fadump is an alternative to Kdump , fadump requires Kdump to be enabled. You can enable fadump on this screen. If you do not want to use Kdump on this system, uncheck Enable kdump . Otherwise, set the amount of memory to reserve for Kdump . You can let the installer reserve a reasonable amount automatically, or you can set any amount manually. When your are satisfied with the settings, click Done to save the configuration and return to the screen. Figure 13.35. Kdump Enablement and Configuration

Commands:
7.239. strace 7.239.1. RHBA-2013:0282 - strace bug fix and enhancement update Updated strace packages that fix two bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The strace packages provide a utility to intercept and record the system calls called and received by a running process. The strace utility can print a record of each system call, its arguments and its return value. The strace utility is useful for diagnosing, debugging and instructional purposes. Bug Fixes BZ#759569 Prior to this update, the strace utility extracted arguments for the "semtimedop" system call from the wrong location on the IBM System z platforms. As a consequence, arguments for the "semtimedop" system call were incorrectly displayed. This update modifies strace to extract the arguments from the correct memory location so that the arguments for the "semtimedop" system call are displayed as expected. BZ#837183 Prior to this update, the strace utility used special breakpoints to trace fork/vfork/clone system calls. As a consequence, sometimes strace could cause applications to crash when following fork/vfork/clone system calls. This update modifies strace to use PTRACE_SETOPTIONS to set the behavior at fork/vfork/clone system calls and applications no longer crash. Enhancement BZ# 809917 Prior to this update, strace incorrectly decoded system calls when tracing a 32-bit process on a 64-bit machine, because strace on IBM System z platforms is not multi-arch aware. This update provides an additional strace executable (strace32) which can be used to trace 32-bit processes on 64-bit machines. All users of strace are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands: