mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Multi-site deployments Red Hat build of Keycloak supports deployments that consist of multiple Red Hat build of Keycloak instances that connect to each other using its Infinispan caches; load balancers can distribute the load evenly across those instances. Those setups are intended for a transparent network on a single site. The Red Hat build of Keycloak high-availability guide goes one step further to describe setups across multiple sites. While this setup adds additional complexity, that extra amount of high availability may be needed for some environments. 1.1. When to use a multi-site setup The multi-site deployment capabilities of Red Hat build of Keycloak are targeted at use cases that: Are constrained to a single AWS Region. Permit planned outages for maintenance. Fit within a defined user and request count. Can accept the impact of periodic outages. 1.2. Supported Configuration Two Openshift single-AZ clusters, in the same AWS Region Provisioned with Red Hat OpenShift Service on AWS (ROSA), either ROSA HCP or ROSA classic. Each Openshift cluster has all its workers in a single Availability Zone. OpenShift version 4.16 (or later). Amazon Aurora PostgreSQL database High availability with a primary DB instance in one Availability Zone, and a synchronously replicated reader in the second Availability Zone Version 16.1 AWS Global Accelerator, sending traffic to both ROSA clusters AWS Lambda to automate failover Any deviation from the configuration above is not supported and any issue must be replicated in that environment for support. Read more on each item in the Building blocks multi-site deployments chapter. 1.3. Maximum load 100,000 users 300 requests per second See the Concepts for sizing CPU and memory resources chapter for more information. 1.4. Limitations During upgrades of Red Hat build of Keycloak or Data Grid both sites needs to be taken offline for the duration of the upgrade. During certain failure scenarios, there may be downtime of up to 5 minutes. After certain failure scenarios, manual intervention may be required to restore redundancy by bringing the failed site back online. During certain switchover scenarios, there may be downtime of up to 5 minutes. For more details on limitations see the Concepts for multi-site deployments chapter. 1.5. steps The different chapters introduce the necessary concepts and building blocks. For each building block, a blueprint shows how to set a fully functional example. Additional performance tuning and security hardening are still recommended when preparing a production setup.

Commands:
8.3. Overview of Packet Reception To better analyze network bottlenecks and performance issues, you need to understand how packet reception works. Packet reception is important in network performance tuning because the receive path is where frames are often lost. Lost frames in the receive path can cause a significant penalty to network performance. Figure 8.1. Network receive path diagram The Linux kernel receives each frame and subjects it to a four-step process: Hardware Reception : the network interface card (NIC) receives the frame on the wire. Depending on its driver configuration, the NIC transfers the frame either to an internal hardware buffer memory or to a specified ring buffer. Hard IRQ : the NIC asserts the presence of a net frame by interrupting the CPU. This causes the NIC driver to acknowledge the interrupt and schedule the soft IRQ operation . Soft IRQ : this stage implements the actual frame-receiving process, and is run in softirq context. This means that the stage pre-empts all applications running on the specified CPU, but still allows hard IRQs to be asserted. In this context (running on the same CPU as hard IRQ, thereby minimizing locking overhead), the kernel actually removes the frame from the NIC hardware buffers and processes it through the network stack. From there, the frame is either forwarded, discarded, or passed to a target listening socket. When passed to a socket, the frame is appended to the application that owns the socket. This process is done iteratively until the NIC hardware buffer runs out of frames, or until the device weight ( dev_weight ). For more information about device weight, refer to Section 8.4.1, "NIC Hardware Buffer" Application receive : the application receives the frame and dequeues it from any owned sockets via the standard POSIX calls ( read , recv , recvfrom ). At this point, data received over the network no longer exists on the network stack. The Red Hat Enterprise Linux Network Performance Tuning Guide available on the Red Hat Customer Portal contains information on packet reception in the Linux kernel, and covers the following areas of NIC tuning: SoftIRQ misses (netdev budget), tuned tuning daemon, numad NUMA daemon, CPU power states, interrupt balancing, pause frames, interrupt coalescence, adapter queue ( netdev backlog), adapter RX and TX buffers, adapter TX queue, module parameters, adapter offloading, Jumbo Frames, TCP and UDP protocol tuning, and NUMA locality. CPU/cache affinity To maintain high throughput on the receive path, it is recommended that you keep the L2 cache hot . As described earlier, network buffers are received on the same CPU as the IRQ that signaled their presence. This means that buffer data will be on the L2 cache of that receiving CPU. To take advantage of this, place process affinity on applications expected to receive the most data on the NIC that shares the same core as the L2 cache. This will maximize the chances of a cache hit, and thereby improve performance.

Commands:
Chapter 59. JmxTransSpec schema reference The type JmxTransSpec has been deprecated. Used in: KafkaSpec Property Property type Description image string The image to use for the JmxTrans. outputDefinitions JmxTransOutputDefinitionTemplate array Defines the output hosts that will be referenced later on. For more information on these properties see, JmxTransOutputDefinitionTemplate schema reference . logLevel string Sets the logging level of the JmxTrans deployment.For more information see, JmxTrans Logging Level . kafkaQueries JmxTransQueryTemplate array Queries to send to the Kafka brokers to define what data should be read from each broker. For more information on these properties see, JmxTransQueryTemplate schema reference . resources ResourceRequirements CPU and memory resources to reserve. template JmxTransTemplate Template for JmxTrans resources.

Commands:
Chapter 3. Generating API keys to automate the functional certification processes A valid Pyxis API key is a token used to access partner-specific certification data through the REST API. With this key, you can directly access your certification components available in the Red Hat Partner Certification tool and seamlessly upload certification results without the need for repeated authentication. Note API keys are tied to specific Organization IDs, allowing access only to the product listings associated with that particular organization. Prerequisites Have access to the Red Hat Partner Certification tool. A valid component ID for your certification components on the Red Hat Partner Certification tool. Procedure Follow the procedure to generate the API keys: After logging in to the Red Hat Partner Certification tool, go to the Certification management tab. From the Resources listing, click API keys . The API Keys page opens. Click Add API key . The Add API Keys dialog opens. Enter a unique key in the Name text box. Enter a brief description about the newly created key including its purpose in the Description text box. Click Confirm . A new token is generated. The Copy Token wizard opens, allowing you to copy the generated API key. Click the copy icon to the generated API key to save it in a secured location. Important Red Hat doesn't store your API keys. If you don't save the key now, you can't retrieve it after closing this wizard. Verification The new API key is listed on the API Keys page including the following details: Name Description User Name Created Time Actions - Click Revoke , to delete the key.

Commands:
5.261. python-rhsm 5.261.1. RHBA-2012:0805 - python-rhsm bug fix and enhancement update Updated python-rhsm packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The python-rhsm package contains a library for communicating with the representational state transfer (REST) interface of Red Hat's subscription and content service. This interface is used by the Subscription Management tools for management of system entitlements, certificates, and access to content. Bug Fixes BZ# 720372 Previously, Subscription Manager had the fakamai-cp1.pem certificate installed in the /etc/rhsm/ca/fakamai-cp1.pem directory after installation. However, the certificate serves only for testing purposes and is not needed by the tool itself. With this update, the certificate has been removed. BZ# 744654 If the subscription-manager command was issued with an incorrect or empty --server.port option, the command failed with a traceback. With this update, the tool now sets the provided port value as expected and no traceback is returned. BZ# 803773 If the activation key contained non-ASCII characters, the registration failed with the following error: This happened due to an incorrect conversion of the key into the URL address. With this update, subscription-manager converts the characters correctly and the registration succeeds in the scenario described. BZ# 807721 Several configuration settings had no default value defined in the Red Hat Subscription Manager (RHSM), which could cause some commands to return a traceback. The default RHSM values are now set as expected and the problem no longer occurs. BZ# 822965 When the user defined a proxy server in rhsm.conf, the Subscription Manager did not work and returned the "unknown URL type" error. This happened because the "Host" header was not sent up to the CDN when acquiring the list of releases using a proxy. With this update, the "Host" header is sent to the CDN and the proxy definition in rhsm.conf is processed as expected. Enhancement BZ# 785247 The bug fixes and some of the new features introduced in the python-rhsm package on Red Hat Enterprise Linux 5.8 have been backported into the python-rhsm on Red Hat Enterprise Linux 6.3. All users of python-rhsm are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Network error. Please check the connection details, or see /var/log/rhsm/rhsm.log for more information.
Chapter 13. Finding and cleaning stale subvolumes (Technology Preview) Sometimes stale subvolumes don't have a respective k8s reference attached. These subvolumes are of no use and can be deleted. You can find and delete stale subvolumes using the ODF CLI tool. Important Deleting stale subvolumes using the ODF CLI tool is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information, see Technology Preview Features Support Scope . Prerequisites Download the OpenShift Data Foundation command line interface (CLI) tool. With the Data Foundation CLI tool, you can effectively manage and troubleshoot your Data Foundation environment from a terminal. You can find a compatible version and download the CLI tool from the customer portal . Procedure Find the stale subvolumes by using the --stale flag with the subvolumes command: Example output: Delete the stale subvolumes: Replace <subvolumes> with a comma separated list of subvolumes from the output of the first command. The subvolumes must be of the same filesystem and subvolumegroup. Replace <filesystem> and <subvolumegroup> with the filesystem and subvolumegroup from the output of the first command. For example: Example output:

Commands:
odf subvolume ls --stale
Filesystem Subvolume Subvolumegroup State ocs-storagecluster-cephfilesystem csi-vol-427774b4-340b-11ed-8d66-0242ac110004 csi stale ocs-storagecluster-cephfilesystem csi-vol-427774b4-340b-11ed-8d66-0242ac110005 csi stale
odf subvolume delete <subvolumes> <filesystem> <subvolumegroup>
odf subvolume delete csi-vol-427774b4-340b-11ed-8d66-0242ac110004,csi-vol-427774b4-340b-11ed-8d66-0242ac110005 ocs-storagecluster csi
Info: subvolume csi-vol-427774b4-340b-11ed-8d66-0242ac110004 deleted Info: subvolume csi-vol-427774b4-340b-11ed-8d66-0242ac110004 deleted
Chapter 7. OLM v1 7.1. About Operator Lifecycle Manager v1 (Technology Preview) Operator Lifecycle Manager (OLM) has been included with OpenShift Container Platform 4 since its initial release. OpenShift Container Platform 4.18 includes components for a -generation iteration of OLM as a Generally Available (GA) feature, known during this phase as OLM v1 . This updated framework evolves many of the concepts that have been part of versions of OLM and adds new capabilities. Starting in OpenShift Container Platform 4.17, documentation for OLM v1 has been moved to the following new guide: Extensions (OLM v1)

Commands:
Chapter 2. Embedded caches Add Data Grid as a dependency to your Java project and use embedded caches that increase application performance and give you capabilities to handle complex use cases. 2.1. Embedded cache tutorials You can run embedded cache tutorials directly in your IDE or from the command line as follows: USD mvn -s /path/to/maven-settings.xml clean package exec:exec Tutorial link Description Distributed caches Demonstrates how Distributed Caches work. Replicated caches Demonstrates how Replicated Caches work. Invalidated caches Demonstrates how Invalidated Caches work. Transactions Demonstrates how transactions work. Streams Demonstrates how Distributed Streams work. JCache integration Demonstrates how JCache works. Functional Maps Demonstrates how Functional Map API works. Map API Demonstrates how the Map API works with Data Grid caches. Multimap Demonstrates how to use Multimap. Queries Uses Data Grid Query to perform full-text queries on cache values. Clustered Listeners Detects when data changes in an embedded cache with Clustered Listeners. Counters Demonstrates how to use an embedded Clustered Counter. Clustered Locks Demonstrates how to use an embedded Clustered Lock. Clustered execution Demonstrates how to use an embedded Clustered Counter. Data Grid documentation You can find more resources about embedded caches in our documentation at: Embedding Data Grid Caches Querying Data Grid caches 2.2. Kubernetes and Openshift tutorial This tutorial contains instructions on how to run Infinispan library mode (as a microservice) in Kubernetes/OpenShift. Prerequisites: Maven and Docker daemon running in the background. Prerequisites A running Openshift or Kubernetes cluster Building the tutorial This tutorial is built using the maven command: mvn package Note that target/ directory contains additional directories like docker (with generated Dockerfile) and classes/META-INF/jkube with Kubernetes and OpenShift deployment templates. Tip If the Docker Daemon is down, the build will omit processing Dockerfiles. Use docker profile to turn it on manually. Deploying the tutorial to Kubernetes This is handle by the JKube maven plugin, just invoke: mvn k8s:build k8s:push k8s:resource k8s:apply -Doptions.image=<IMAGE_NAME> 1 1 IMAGE_NAME must be replaced with the FQN of the container to deploy to Kubernetes. This container must be created in a repository that you have permissions to push to and is accessible from within your Kubernetes cluster. Viewing and scaling up Everything should be up and running at this point. Now login into the OpenShift or Kubernetes cluster and scale the application kubectl scale --replicas=3 deployment/USD(kubectl get rs --namespace=myproject | grep infinispan | awk '{print USD1}') --namespace=myproject Undeploying the tutorial This is handled by the JKube maven plugin, just invoke:

Commands:
mvn -s /path/to/maven-settings.xml clean package exec:exec
mvn package
mvn k8s:build k8s:push k8s:resource k8s:apply -Doptions.image=<IMAGE_NAME> 1
scale --replicas=3 deployment/USD(kubectl get rs --namespace=myproject | grep infinispan | awk '{print USD1}') --namespace=myproject
mvn k8s:undeploy
9.15. XSD Schema File You can import XML Schema file (XSD) files using the steps below. In Model Explorer, right-click and then click Import... or click the File > Import... action in the toolbar or select a project, folder or model in the tree and click Import... Select the import option Teiid Designer > XML Schemas and click > . Select either Import XSD Schemas from file system or Import XSD Schemas via URL and click > . If importing from file system, the Import XSD Files dialog is displayed. Click the Browse button to find the directory that contains the XSD file(s) you wish to import. To select all of the XSD files in the directory, click the checkbox to the folder in the left panel. To select individual XSD files, click the check boxes to the files you want in the right panel. Figure 9.60. Select XSD From File System If importing from URL, select the Import XML Schemas via URL option and click OK to display the final Add XML Schema URLs wizard page. Figure 9.61. Add XML Schema URLs Dialog Click the Add XML Schema URL button . Enter a valid schema URL. Click OK . Schema will be validated and resulting entry added to the list of XML Schema URLs. Figure 9.62. Add XSD Schema URLs The schema URL is now displayed in the XML Schema URLs list. Figure 9.63. Add XSD Schema URLs Click Finish . Note XSD files may have dependent files. This importer will determine these dependencies and import these as well if Add Dependent Schema Files is selected.

Commands:
F.3. About JBoss Cache Red Hat JBoss Cache is a tree-structured, clustered, transactional cache that can also be used in a standalone, non-clustered environment. It caches frequently accessed data in-memory to prevent data retrieval or calculation bottlenecks that occur while enterprise features such as Java Transactional API (JTA) compatibility, eviction and persistence are provided. JBoss Cache is the predecessor to Infinispan and Red Hat JBoss Data Grid. Report a bug

Commands:
4.323. tftp 4.323.1. RHBA-2012:1436 - ftp bug fix update Updated ftp packages that fix three bugs are now available for Red Hat Enterprise Linux 6. The ftp packages provide the standard UNIX command line File Transfer Protocol (FTP) client. FTP is a widely used protocol for transferring files over the Internet, and for archiving files. Bug Fixes BZ# 871059 Previously, the command line width in the ftp client was limited to 200 characters. With this update, the maximum possible length of the FTP command line is extended to 4296 characters. BZ# 871071 Prior to this update, "append", "put", and "send" commands were causing system memory to leak. The memory holding the ftp command was not freed appropriately. With this update, the underlying source code has been improved to correctly free the system resources and the memory leaks are no longer present. BZ# 871546 Previously, if a macro longer than 200 characters was defined and then used after a connection, the ftp client crashed due to a buffer overflow. With this update, the underlying source code was updated and the buffer that holds memory for the macro name was extended. It now matches the length of the command line limit mentioned above. As a result, the ftp client no longer crashes when a macro with a long name is executed. All users of ftp are advised to upgrade to these updated packages, which fix these bugs. 4.323.2. RHBA-2011:1133 - tftp bug fix update Updated tftp packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The Trivial File Transfer Protocol (TFTP) is normally used only for booting diskless workstations. The tftp package provides the user interface for TFTP, which allows users to transfer files to and from a remote machine. The tftp-server package provides the server for TFTP which allows users to transfer files to and from a remote machine. Bug Fixes BZ# 655830 When the small files were transferred and the "-v" option was enabled, the tftp client printed incorrect statistics about the transfer. This update fixes printing of the transfer statistics. BZ# 714240 The tftpd daemon did not correctly handle the utimeout option value. If a client specified a utimeout value within the permitted range, it caused the tftpd process to crash. This crash only affected the current tftp request. All users of tftp and tftp-server should upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 9. Changes in 3scale Note In 3scale 2.14, support for deploying databases within the cluster as part of the standard 3scale deployment was deprecated. In 3scale 2.16, Red Hat supports only self-deployed databases, whether within the cluster or external to it. This section lists current and future 3scale changes. Deprecated features 3scale support for OpenTracing is now deprecated in favor of OpenTelemetry. In the upcoming version, 3scale 2.16, OpenTracing will no longer be available. 3scale Toolbox Command Line Tool is deprecated and we will no longer incorporate further enhancements. The recommended way for provisioning and automation needs, is the 3scale Application Capabilities operator. OpenShift APIs for Data Protection is now the standard and recommended backup and restore mechanism in 3scale. The old backup and restore procedures are deprecated and will be removed from future versions documentation. 3scale no longer supports slaves for Redis configurations. If slaves are enabled on internal Redis configurations, the operator will override and disable them.

Commands:
13.5. Changing the Index Sort Order By default, indexes are sorted alphabetically, in descending ASCII order. This is true for every attribute, even attributes which may have numeric attribute values like Integer or TelephoneNumber. It is possible to change the sort method by changing the matching rule set for the attribute. 13.5.1. Changing the Sort Order Using the Command Line To change the sort order using the command line, change the nsMatchingRule for the attribute index. For example:

Commands:
ldapmodify -D "cn=Directory Manager" -W -x dn: cn=sn,cn=index,cn=Example1,cn=ldbm database,cn=plugins,cn=config changetype:modify replace:nsMatchingRule nsMatchingRule: integerOrderingMatch