mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Building blocks active-passive deployments The following building blocks are needed to set up an active-passive deployment with synchronous replication. The building blocks link to a blueprint with an example configuration. They are listed in the order in which they need to be installed. Note We provide these blueprints to show a minimal functionally complete example with a good baseline performance for regular installations. You would still need to adapt it to your environment and your organization's standards and security best practices. 3.1. Prerequisites Understanding the concepts laid out in the Concepts for active-passive deployments chapter. 3.2. Two sites with low-latency connection Ensures that synchronous replication is available for both the database and the external Data Grid. Suggested setup: Two AWS Availablity Zones within the same AWS Region. Not considered: Two regions on the same or different continents, as it would increase the latency and the likelihood of network failures. Synchronous replication of databases as a services with Aurora Regional Deployments on AWS is only available within the same region. 3.3. Environment for Red Hat build of Keycloak and Data Grid Ensures that the instances are deployed and restarted as needed. Suggested setup: Red Hat OpenShift Service on AWS (ROSA) deployed in each availability zone. Not considered: A stretched ROSA cluster which spans multiple availability zones, as this could be a single point of failure if misconfigured. 3.4. Database A synchronously replicated database across two sites. Blueprint: Deploy AWS Aurora in multiple availability zones . 3.5. Data Grid A deployment of Data Grid that leverages the Data Grid's Cross-DC functionality. Blueprint: Deploy Data Grid for HA with the Data Grid Operator using the Data Grid Operator, and connect the two sites using Data Grid's Gossip Router. Not considered: Direct interconnections between the Kubernetes clusters on the network layer. It might be considered in the future. 3.6. Red Hat build of Keycloak A clustered deployment of Red Hat build of Keycloak in each site, connected to an external Data Grid. Blueprint: Deploy Red Hat build of Keycloak for HA with the Red Hat build of Keycloak Operator together with Connect Red Hat build of Keycloak with an external Data Grid and the Aurora database. 3.7. Load balancer A load balancer which checks the /lb-check URL of the Red Hat build of Keycloak deployment in each site. Blueprint: Deploy an AWS Route 53 loadbalancer . Not considered: AWS Global Accelerator as it supports only weighted traffic routing and not active-passive failover. To support active-passive failover, additional logic using, for example, AWS CloudWatch and AWS Lambda would be necessary to simulate the active-passive handling by adjusting the weights when the probes fail.

Commands:
Chapter 10. Running certification tests by using CLI and downloading the results file To run the certification tests by using CLI you must prepare the host and download the test plan to the SUT. After running the tests, download the results and review them. 10.1. Using the test plan to prepare the host under test for testing Running the provision command performs a number of operations, such as setting up passwordless SSH communication with the test server, installing the required packages on your system based on the certification type, and creating a final test plan to run, which is a list of common tests taken from both the test plan provided by Red Hat and tests generated on discovering the system requirements. For instance, required hardware or software packages will be installed if the test plan is designed for certifying a hardware or a software product. Prerequisites You have the hostname or the IP address of the test server. Procedure Run the provision command in either way. The test plan will automatically get downloaded to your system. If you have already downloaded the test plan: Replace <path_to_test_plan_document> with the test plan file saved on your system. Follow the on-screen instructions. If you have not downloaded the test plan: Follow the on-screen instructions and enter your Certification ID when prompted. When prompted, provide the hostname or the IP address of the test server to set up passwordless SSH. You are prompted only the first time you add a new system. 10.2. Running the certification tests using CLI Procedure Run the following command: When prompted, choose whether to run each test by typing yes or no . You can also run particular tests from the list by typing select . Note After a test reboot, rhcert is running in the background to verify the image. Use tail -f / var /log/rhcert/RedHatCertDaemon.log to see the current progress and status of the verification. 10.3. Reviewing and downloading the results file of the executed test plan Procedure Download the test results file: Download the results file by using the rhcert-save command to your local system. Additional resources For more details on setting up and using cockpit for running the certification tests, see the Appendix .

Commands:
rhcert-provision <path_to_test_plan_document>
rhcert-provision
rhcert-run
rhcert-save
12.3. Configuring the Log Format You can configure the Red Hat Gluster Storage Server to generate log messages either with message IDs or without them. To know more about these options, see topic Configuring Volume Options in the Red Hat Gluster Storage Administration Guide . To configure the log-format for bricks of a volume: Example 12.1. Generate log files with with-msg-id : Example 12.2. Generate log files with no-msg-id : To configure the log-format for clients of a volume: Example 12.3. Generate log files with with-msg-id : Example 12.4. Generate log files with no-msg-id : To configure the log format for glusterd : Example 12.5. Generate log files with with-msg-id : Example 12.6. Generate log files with no-msg-id : See Also: Section 11.1, "Configuring Volume Options"

Commands:
gluster volume set VOLNAME diagnostics.brick-log-format <value>
gluster volume set testvol diagnostics.brick-log-format with-msg-id
gluster volume set testvol diagnostics.brick-log-format no-msg-id
gluster volume set VOLNAME diagnostics.client-log-format <value>
gluster volume set testvol diagnostics.client-log-format with-msg-id
gluster volume set testvol diagnostics.client-log-format no-msg-id
glusterd --log-format=<value>
glusterd --log-format=with-msg-id
glusterd --log-format=no-msg-id
Chapter 5. Network connections 5.1. Connection Options This section describes how to configure how to configure connections. The ConnectionOptions object can be provided to a Client instance when creating a new connection and allows configuration of several different aspects of the resulting Connection instance. ConnectionOptions can be passed in the connect method on IClient and are used to configure Example: Configuring authentication final ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.user(System.getProperty("USER")); connectionOptions.password(System.getProperty("PASSWORD")); Connection connection = client.connect(serverHost, serverPort, connectionOptions); For a definitive list of options refer to ConnectionOptions 5.1.1. Connection Transport Options The ConnectionOptions object exposes a set of configuration options for the underlying I/O transport layer known as the TransportOptions which allows for fine grained configuration of network level options. Example: Configuring transport options final ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.transportOptions().tcpNoDelay(false); Connection connection = client.connect(serverHost, serverPort, connectionOptions); For a definitive list of options refer to TransportOptions 5.2. Reconnect and failover When creating a new connection it is possible to configure that connection to perform automatic connection recovery. Example: Configuring transport reconnection and failover final ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.reconnectOptions().reconnectEnabled(true); connectionOptions.reconnectOptions().reconnectDelay(30000); connectionOptions.reconnectOptions().addReconnectLocation(hostname, port); Connection connection = client.connect(serverHost, serverPort, connectionOptions); For a definitive list of options refer to ReconnectionOptions

Commands:
final ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.user(System.getProperty("USER")); connectionOptions.password(System.getProperty("PASSWORD")); Connection connection = client.connect(serverHost, serverPort, connectionOptions);
final ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.transportOptions().tcpNoDelay(false); Connection connection = client.connect(serverHost, serverPort, connectionOptions);
final ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.reconnectOptions().reconnectEnabled(true); connectionOptions.reconnectOptions().reconnectDelay(30000); connectionOptions.reconnectOptions().addReconnectLocation(hostname, port); Connection connection = client.connect(serverHost, serverPort, connectionOptions);
11.3. Removing Swap Space Sometimes it can be prudent to reduce swap space after installation. For example, say you downgraded the amount of RAM in your system from 1 GB to 512 MB, but there is 2 GB of swap space still assigned. It might be advantageous to reduce the amount of swap space to 1 GB, since the larger 2 GB could be wasting disk space. You have three options: remove an entire LVM2 logical volume used for swap, remove a swap file, or reduce swap space on an existing LVM2 logical volume. 11.3.1. Reducing Swap on an LVM2 Logical Volume To reduce an LVM2 swap logical volume (assuming /dev/VolGroup00/LogVol01 is the volume you want to extend): Disable swapping for the associated logical volume: Reduce the LVM2 logical volume by 512 MB: Format the new swap space: Enable the extended logical volume: Test that the logical volume has been reduced properly:

Commands:
swapoff -v /dev/VolGroup00/LogVol01
lvm lvreduce /dev/VolGroup00/LogVol01 -L -512M
mkswap /dev/VolGroup00/LogVol01
swapon -va
cat /proc/swaps # free
Chapter 4. Deprecated features The features deprecated in this release, and that were supported in releases of AMQ Streams, are outlined below. 4.1. Java 8 Support for Java 8 was deprecated in Kafka 3.0.0 and AMQ Streams 2.0. Java 8 will be unsupported for all AMQ Streams components, including clients, in the future. AMQ Streams supports Java 11. Use Java 11 when developing new applications. Plan to migrate any applications that currently use Java 8 to Java 11. 4.2. Kafka MirrorMaker 1 Kafka MirrorMaker replicates data between two or more active Kafka clusters, within or across data centers. Kafka MirrorMaker 1 is deprecated for Kafka 3.0.0 and will be removed in Kafka 4.0.0. MirrorMaker 2.0 will be the only version available. MirrorMaker 2.0 is based on the Kafka Connect framework, connectors managing the transfer of data between clusters. As a consequence, the AMQ Streams KafkaMirrorMaker custom resource which is used to deploy Kafka MirrorMaker 1 has been deprecated. The KafkaMirrorMaker resource will be removed from AMQ Streams when Kafka 4.0.0 is adopted. If you are using MirrorMaker 1 (referred to as just MirrorMaker in the AMQ Streams documentation), use the KafkaMirrorMaker2 custom resource with the IdentityReplicationPolicy . MirrorMaker 2.0 renames topics replicated to a target cluster. IdentityReplicationPolicy configuration overrides the automatic renaming. Use it to produce the same active/passive unidirectional replication as MirrorMaker 1. See Kafka MirrorMaker 2.0 cluster configuration . 4.3. Identity replication policy Identity replication policy is used with MirrorMaker 2.0 to override the automatic renaming of remote topics. Instead of prepending the name with the name of the source cluster, the topic retains its original name. This optional setting is useful for active/passive backups and data migration. The AMQ Streams Identity Replication Policy class ( io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy ) is now deprecated and will be removed in the future. You can update to use Kafka's own Identity Replication Policy ( class org.apache.kafka.connect.mirror.IdentityReplicationPolicy ). See Kafka MirrorMaker 2.0 cluster configuration . 4.4. ListenerStatus type property The type property of ListenerStatus has been deprecated and will be removed in the future. ListenerStatus is used to specify the addresses of internal and external listeners. Instead of using the type , the addresses are now specified by name . See ListenerStatus schema reference . 4.5. Cruise Control capacity configuration The disk and cpuUtilization capacity configuration properties have been deprecated, are ignored, and will be removed in the future. The properties were used in setting capacity limits in optimization proposals to determine if resource-based optimization goals are being broken. Disk and CPU capacity limits are now automatically generated by AMQ Streams. See Cruise Control configuration .

Commands:
5.5. Hot Plugging vCPUs You can hot plug vCPUs. Hot plugging means enabling or disabling devices while a virtual machine is running. Important Hot unplugging a vCPU is only supported if the vCPU was previously hot plugged. A virtual machine's vCPUs cannot be hot unplugged to less vCPUs than it was originally created with. The following prerequisites apply: The virtual machine's Operating System must be explicitly set in the New Virtual Machine or Edit Virtual Machine window. The virtual machine's operating system must support CPU hot plug. See the table below for support details. Windows virtual machines must have the guest agents installed. See Installing the Guest Agents and Drivers on Windows . Hot Plugging vCPUs Click Compute Virtual Machines and select a running virtual machine. Click Edit . Click the System tab. Change the value of Virtual Sockets as required. Click OK . Table 5.1. Operating System Support Matrix for vCPU Hot Plug Operating System Version Architecture Hot Plug Supported Hot Unplug Supported Red Hat Enterprise Linux Atomic Host 7 x86 Yes Yes Red Hat Enterprise Linux 6.3+ x86 Yes Yes Red Hat Enterprise Linux 7.0+ x86 Yes Yes Red Hat Enterprise Linux 7.3+ PPC64 Yes Yes Red Hat Enterprise Linux 8.0+ x86 Yes Yes Microsoft Windows Server 2012 R2 All x64 Yes No Microsoft Windows Server 2016 Standard, Datacenter x64 Yes No Microsoft Windows Server 2019 Standard, Datacenter x64 Yes No Microsoft Windows 8.x All x86 Yes No Microsoft Windows 8.x All x64 Yes No Microsoft Windows 10 All x86 Yes No Microsoft Windows 10 All x64 Yes No

Commands:
4.2.4. I/O Monitoring (By Device) This section describes how to monitor I/O activity on a specific device. traceio2.stp traceio2.stp takes 1 argument: the whole device number. To get this number, use stat -c "0x%D" directory , where directory is located in the device you wish to monitor. The usrdev2kerndev() function converts the whole device number into the format understood by the kernel. The output produced by usrdev2kerndev() is used in conjunction with the MKDEV() , MINOR() , and MAJOR() functions to determine the major and minor numbers of a specific device. The output of traceio2.stp includes the name and ID of any process performing a read/write, the function it is performing (that is vfs_read or vfs_write ), and the kernel device number. The following example is an excerpt from the full output of stap traceio2.stp 0x805 , where 0x805 is the whole device number of /home . /home resides in /dev/sda5 , which is the device we wish to monitor. Example 4.8. traceio2.stp Sample Output

Commands:
#! /usr/bin/env stap global device_of_interest probe begin { /* The following is not the most efficient way to do this. One could directly put the result of usrdev2kerndev() into device_of_interest. However, want to test out the other device functions */ dev = usrdev2kerndev(USD1) device_of_interest = MKDEV(MAJOR(dev), MINOR(dev)) } probe vfs.write, vfs.read { if (dev == device_of_interest) printf ("%s(%d) %s 0x%x\n", execname(), pid(), probefunc(), dev) }
[...] synergyc(3722) vfs_read 0x800005 synergyc(3722) vfs_read 0x800005 cupsd(2889) vfs_write 0x800005 cupsd(2889) vfs_write 0x800005 cupsd(2889) vfs_write 0x800005 [...]
Chapter 1. Red Hat Quay tenancy model Before creating repositories to contain your container images in Red Hat Quay, you should consider how these repositories will be structured. With Red Hat Quay, each repository requires a connection with either an Organization or a User . This affiliation defines ownership and access control for the repositories. 1.1. Tenancy model Organizations provide a way of sharing repositories under a common namespace that does not belong to a single user. Instead, these repositories belong to several users in a shared setting, such as a company. Teams provide a way for an Organization to delegate permissions. Permissions can be set at the global level (for example, across all repositories), or on specific repositories. They can also be set for specific sets, or groups, of users. Users can log in to a registry through the web UI or a by using a client like Podman and using their respective login commands, for example, USD podman login . Each user automatically gets a user namespace, for example, <quay-server.example.com>/<user>/<username> , or quay.io/<username> if you are using Quay.io. Superusers have enhanced access and privileges through the Super User Admin Panel in the user interface. Superuser API calls are also available, which are not visible or accessible to normal users. Robot accounts provide automated access to repositories for non-human users like pipeline tools. Robot accounts are similar to OpenShift Container Platform Service Accounts . Permissions can be granted to a robot account in a repository by adding that account like you would another user or team.

Commands:
Chapter 5. Changes in microservices patterns This section explains the changes in microservices patterns. 5.1. Changes in Eclipse Vert.x circuit breaker The following section describes the changes in Eclipse Vert.x circuit breaker. 5.1.1. Removed execute command methods in circuit breaker The following methods have been removed from the CircuitBreaker class because they cannot be used with futures. Removed methods Replacing methods CircuitBreaker.executeCommand() CircuitBreaker.execute() CircuitBreaker.executeCommandWithFallback() CircuitBreaker.executeWithFallback() 5.2. Changes in Eclipse Vert.x service discovery The following section describes the changes in Eclipse Vert.x service discovery. 5.2.1. Removed create methods from service discovery that contain ServiceDiscovery argument The following create methods in service discovery that have Handler<AmqpMessage> as an argument have been removed. These methods cannot be used with futures. Removed methods Replacing methods ServiceDiscovery.create(... , Handler<ServiceDiscovery> completionHandler) ServiceDiscovery.create(Vertx) ServiceDiscovery.create(... , Handler<ServiceDiscovery> completionHandler) ServiceDiscovery.create(Vertx, ServiceDiscoveryOptions) 5.2.2. Service importer and exporter methods are no longer fluent The ServiceDiscovery.registerServiceImporter() and ServiceDiscovery.registerServiceExporter() methods are no longer fluent. The methods return Future<Void> . 5.2.3. Kubernetes service importer is no longer registered automatically The vertx-service-discovery-bridge-kubernetes adds the KubernetesServiceImporter discovery bridge. The bridge imports services from Kubernetes or Openshift into the Eclipse Vert.x service discovery. From Eclipse Vert.x 4, this bridge is no longer registered automatically. Even if you have added the bridge in the classpath of your Maven project, it will not be automatically registered. You must manually register the bridge after creating the ServiceDiscovery instance. The following example shows you how to manually register the bridge. JsonObject defaultConf = new JsonObject(); serviceDiscovery.registerServiceImporter(new KubernetesServiceImporter(), defaultConf);

Commands:
JsonObject defaultConf = new JsonObject(); serviceDiscovery.registerServiceImporter(new KubernetesServiceImporter(), defaultConf);
14.8.12. smbmount smbmount <//server/share> <mount_point> <-o options> The smbmount program uses the low-level smbmnt program to mount an smbfs file system (Samba share). The mount -t smbfs <//server/share> <mount_point> <-o options> command also works. For example:

Commands:
~]# smbmount //wakko/html /mnt/html -o username=kristin Password: <password> ls -l /mnt/html total 0 -rwxr-xr-x 1 root root 0 Jan 29 08:09 index.html
7.17. bind-dyndb-ldap 7.17.1. RHBA-2015:1259 - bind-dyndb-ldap bug fix update Updated bind-dyndb-ldap packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The dynamic LDAP back end is a plug-in for BIND that provides back-end capabilities for LDAP databases. It features support for dynamic updates and internal caching that helps to reduce the load on LDAP servers. Bug Fixes BZ# 1175318 Previously, the bind-dyndb-ldap 2.x driver (used in Red Hat Enterprise Linux 6.x) did not handle forward zones correctly when it was in the same replication topology as bind-dyndb-ldap 6.x (used in Red Hat Enterprise Linux 7.1). As a consequence, forward zones stopped working on all replicas. The underlying source code has been patched to fix this bug, and forward zones now continue to work in the described situation. BZ# 1142176 The bind-dyndb-ldap library incorrectly compared current time and the expiration time of the Kerberos ticket used for authentication to an LDAP server. As a consequence, the Kerberos ticket was not renewed under certain circumstances, which caused the connection to the LDAP server to fail. The connection failure often happened after a BIND service reload was triggered by the logrotate utility. A patch has been applied to fix this bug, and Kerberos tickets are correctly renewed in this scenario. BZ# 1126841 Prior to this update, the bind-dyndb-ldap plug-in incorrectly locked certain data structures. Consequently, a race condition during forwarder address reconfiguration could cause BIND to terminate unexpectedly. This bug has been fixed, bind-dyndb-ldap now locks data structures properly, and BIND no longer crashes in this scenario. BZ# 1219568 Previously, the bind-dyndb-ldap plug-in incorrectly handled timeouts which occurred during LDAP operations. As a consequence, under very specific circumstances, the BIND daemon could terminate unexpectedly. With this update, bind-dyndb-ldap has been fixed to correctly handle timeouts during LDAP operations and the BIND daemon no longer crashes in this scenario. BZ# 1183805 The documentation for bind-dyndb-ldap-2.3 located in the /usr/share/doc/bind-dyndb-ldap-2.3/README file incorrectly stated that the "idnsAllowTransfer" and "idnsAllowQuery" LDAP attributes are multi-valued. Consequently, users were not able to configure DNS zone transfer and query acess control lists according to the documentation. The documentation has been fixed to explain the correct attribute syntax. Users of bind-dyndb-ldap are advised to upgrade to these updated packages, which fix these bugs.

Commands:
B.20. fence-agents B.20.1. RHBA-2011:0363 - fence-agents bug fix update An updated fence-agents package that fixes a bug is now available for Red Hat Enterprise Linux 6. Red Hat fence agents are a collection of scripts to handle remote power management for several devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster. Bug Fix BZ# 680522 A bug fix for a advisory, the RHEA-2010:0904 enhancement update, stated that the Brocade 200E, Brocade 300, Brocade 4100, Brocade 4900, and Brocade 5100 fencing devices are now supported by the fence_brocade agent. However, the fence_brocade agent was not included in the updated package. This update corrects this error, and the fence_brocade agent is now included in the package as expected. All users of fence-agents are advised to upgrade to this updated package, which resolves this issue.

Commands: