mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 118. KafkaMirrorMakerProducerSpec schema reference Used in: KafkaMirrorMakerSpec Full list of KafkaMirrorMakerProducerSpec schema properties Configures a MirrorMaker producer. 118.1. abortOnSendFailure Use the producer.abortOnSendFailure property to configure how to handle message send failure from the producer. By default, if an error occurs when sending a message from Kafka MirrorMaker to a Kafka cluster: The Kafka MirrorMaker container is terminated in OpenShift. The container is then recreated. If the abortOnSendFailure option is set to false , message sending errors are ignored. 118.2. config Use the producer.config properties to configure Kafka options for the producer as keys. The values can be one of the following JSON types: String Number Boolean Exceptions You can specify and configure the options listed in the Apache Kafka configuration documentation for producers . However, AMQ Streams takes care of configuring and managing options related to the following, which cannot be changed: Kafka cluster bootstrap address Security (encryption, authentication, and authorization) Interceptors Properties with the following prefixes cannot be set: bootstrap.servers interceptor.classes sasl. security. ssl. If the config property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file. All other supported options are forwarded to MirrorMaker, including the following exceptions to the options configured by AMQ Streams: Any ssl configuration for supported TLS versions and cipher suites Important The Cluster Operator does not validate keys or values in the config object provided. If an invalid configuration is provided, the MirrorMaker cluster might not start or might become unstable. In this case, fix the configuration so that the Cluster Operator can roll out the new configuration to all MirrorMaker nodes. 118.3. KafkaMirrorMakerProducerSpec schema properties Property Description bootstrapServers A list of host:port pairs for establishing the initial connection to the Kafka cluster. string abortOnSendFailure Flag to set the MirrorMaker to exit on a failed send. Default value is true . boolean authentication Authentication configuration for connecting to the cluster. The type depends on the value of the authentication.type property within the given object, which must be one of [tls, scram-sha-256, scram-sha-512, plain, oauth]. KafkaClientAuthenticationTls , KafkaClientAuthenticationScramSha256 , KafkaClientAuthenticationScramSha512 , KafkaClientAuthenticationPlain , KafkaClientAuthenticationOAuth config The MirrorMaker producer config. Properties with the following prefixes cannot be set: ssl., bootstrap.servers, sasl., security., interceptor.classes (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols). map tls TLS configuration for connecting MirrorMaker to the cluster. ClientTls

Commands:
10.2.3. Using the QEMU Guest Agent The QEMU guest agent protocol (QEMU GA) package, qemu-guest-agent , is fully supported in Red Hat Enterprise Linux 6.5 and newer. However, there are the following limitations with regards to isa-serial/virtio-serial transport: The qemu-guest-agent cannot detect whether or not a client has connected to the channel. There is no way for a client to detect whether or not qemu-guest-agent has disconnected or reconnected to the back-end. If the virtio-serial device resets and qemu-guest-agent has not connected to the channel (generally caused by a reboot or hot plug), data from the client will be dropped. If qemu-guest-agent has connected to the channel following a virtio-serial device reset, data from the client will be queued (and eventually throttled if available buffers are exhausted), regardless of whether or not qemu-guest-agent is still running or connected.

Commands:
Chapter 4. Testing Evacuation with Instance HA Warning The following procedure involves deliberately crashing a Compute node. Doing this forces the automated evacuation of instances through Instance HA. Boot one or more instances on the overcloud before crashing the Compute node that hosts the instances to test. Log in to the Compute node that hosts the instances, using the compute-n format. Crash the Compute node. Wait a few minutes and then verify that these instances re-spawned on another Compute nodes.

Commands:
stack@director USD . overcloudrc stack@director USD nova boot --image cirros --flavor 2 test-failover stack@director USD nova list --fields name,status,host
stack@director USD . stackrc stack@director USD ssh -l heat-admin compute-n heat-admin@ compute-n USD
heat-admin@ compute-n USD echo c > /proc/sysrq-trigger
stack@director USD nova list --fields name,status,host stack@director USD nova service-list
Chapter 77. KafkaClientAuthenticationPlain schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationPlain schema properties To configure SASL-based PLAIN authentication, set the type property to plain . SASL PLAIN authentication mechanism requires a username and password. Warning The SASL PLAIN mechanism will transfer the username and password across the network in cleartext. Only use SASL PLAIN authentication if TLS encryption is enabled. 77.1. username Specify the username in the username property. 77.2. passwordSecret In the passwordSecret property, specify a link to a Secret containing the password. You can use the secrets created by the User Operator. If required, create a text file that contains the password, in cleartext, to use for authentication: echo -n PASSWORD > MY-PASSWORD .txt You can then create a Secret from the text file, setting your own field name (key) for the password: oc create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt Example Secret for PLAIN client authentication for Kafka Connect apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-password-field-name: LFTIyFRFlMmU2N2Tm The secretName property contains the name of the Secret and the password property contains the name of the key under which the password is stored inside the Secret . Important Do not specify the actual password in the password property. An example SASL based PLAIN client authentication configuration authentication: type: plain username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-password-field-name 77.3. KafkaClientAuthenticationPlain schema properties The type property is a discriminator that distinguishes use of the KafkaClientAuthenticationPlain type from KafkaClientAuthenticationTls , KafkaClientAuthenticationScramSha256 , KafkaClientAuthenticationScramSha512 , KafkaClientAuthenticationOAuth . It must have the value plain for the type KafkaClientAuthenticationPlain . Property Property type Description passwordSecret PasswordSecretSource Reference to the Secret which holds the password. type string Must be plain . username string Username used for the authentication.

Commands:
echo -n PASSWORD > MY-PASSWORD .txt
create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-password-field-name: LFTIyFRFlMmU2N2Tm
authentication: type: plain username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-password-field-name
Chapter 10. 4.7 Release Notes 10.1. New Features The following major enhancements have been introduced in Red Hat Update Infrastructure 4.7. Shared mount options for RHUI Installer have been expanded With this update, the RHUI Installer's shared storage mounting options have been expanded to allow config files, certificate files and log files to be mounted on shared storage. For more information, see rhui-installer --help . HAProxy can be run on RHEL 9 With this update RHUI supports HAProxy running on RHEL 9 even when RHUA is running on RHEL 8. Log file rhui-subscription-sync.log has been relocated With this update log file rhui-subscription-sync.log has been relocated to directory /var/log/rhui from directory /var/log. 10.2. Bug Fixes The following bugs have been fixed in Red Hat Update Infrastructure 4.7 that have a significant impact on users. Unrecognized rhui-manager commands are no longer ignored With this update unrecognized rhui-manager commands are no longer ignored, instead they are reported as unrecognized. Extraneous warnings when no CDSs are configured have been removed In prior versions of RHUI when rhui-manager status was executed, while no CDS nodes where being tracked, warnings were being logged in /var/log/rhui/rhua_ansible.log. With this update such extraneous warnings are not produced. Unnecessary nginx packages are omitted With this update unnecessary nginx packages are no longer installed. Saved versions of repo metadata now limitied to five With this update the number of versions of saved repository metadata is limited to five. In the past, as new packages were added into a repository, a new version of the metadata was generated, potentially happening hundreds of times. Erroneous error messages have been removed With this update empty repos are now exported. In the past, if RHUI was configured with --fetch-missing-symlinks False , the unexported empty repos resulted in "Errors during downloading metadata for repository"

Commands:
Chapter 1. Introduction to Satellite API Red Hat Satellite provides a Representational State Transfer (REST) API. The API provides software developers and system administrators with control over their Red Hat Satellite environment outside of the standard web interface. The REST API is useful for developers and administrators who aim to integrate the functionality of Red Hat Satellite with custom scripts or external applications that access the API over HTTP. 1.1. Overview of the Satellite API The benefits of using the REST API are: Broad client support - any programming language, framework, or system with support for HTTP protocol can use the API. Self-descriptive - client applications require minimal knowledge of the Red Hat Satellite infrastructure because a user discovers many details at runtime. Resource-based model - the resource-based REST model provides a natural way to manage a virtualization platform. You can use the REST API to perform the following tasks: Integrate with enterprise IT systems. Integrate with third-party applications. Perform automated maintenance or error checking tasks. Automate repetitive tasks with scripts. 1.2. Satellite API compared to Hammer CLI For many tasks, you can use both Hammer and Satellite API. You can use Hammer as a human-friendly interface to Satellite API. For example, to test responses to API calls before applying them in a script, use the --debug option to inspect API calls that Hammer issues: hammer --debug organization list . In contrast, scripts that use API commands communicate directly with the Satellite API. For more information, see the Using the Hammer CLI tool .

Commands:
7.3. Moving Resources Due to Connectivity Changes Setting up the cluster to move resources when external connectivity is lost is a two-step process. Add a ping resource to the cluster. The ping resource uses the system utility of the same name to test if a list of machines (specified by DNS host name or IPv4/IPv6 address) are reachable and uses the results to maintain a node attribute called pingd . Configure a location constraint for the resource that will move the resource to a different node when connectivity is lost. Table 5.1, "Resource Properties" describes the properties you can set for a ping resource. Table 7.1. Properties of a ping resources Field Description dampen The time to wait (dampening) for further changes to occur. This prevents a resource from bouncing around the cluster when cluster nodes notice the loss of connectivity at slightly different times. multiplier The number of connected ping nodes gets multiplied by this value to get a score. Useful when there are multiple ping nodes configured. host_list The machines to contact in order to determine the current connectivity status. Allowed values include resolvable DNS host names, IPv4 and IPv6 addresses. The following example command creates a ping resource that verifies connectivity to www.example.com . In practice, you would verify connectivity to your network gateway/router. You configure the ping resource as a clone so that the resource will run on all cluster nodes. The following example configures a location constraint rule for the existing resource named Webserver . This will cause the Webserver resource to move to a host that is able to ping www.example.com if the host that it is currently running on cannot ping www.example.com

Commands:
pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=www.example.com --clone
pcs constraint location Webserver rule score=-INFINITY pingd lt 1 or not_defined pingd
Chapter 1. Troubleshooting OpenShift Lightspeed The following topics provide information to help troubleshoot OpenShift Lightspeed. 1.1. 502 Bad Gateway Errors in the interface If you try to start using OpenShift Lightspeed before the internal components have stabilized, 502 Bad Gateway errors can occur. While all the pods might be running, there can be other console and internal OpenShift Container Platform system components that are not ready. Wait a few minutes and try using OpenShift Lightspeed again. 1.2. Operator Missing from the Operator Hub list If you are not running your OpenShift Container Platform cluster on an x86 architecture, for example OpenShift Local on M1 Mac, you will not see the OpenShift Lightspeed Operator in Operator Hub due to the way the Operator Hub filters architectures. OpenShift Lightspeed is only supported on x86 architecture.

Commands:
Chapter 2. Installing automation content navigator on RHEL As a content creator, you can install automation content navigator on Red Hat Enterprise Linux (RHEL) 8.6 or later. 2.1. Installing automation content navigator on RHEL from an RPM You can install automation content navigator on Red Hat Enterprise Linux (RHEL) from an RPM. Prerequisites You have installed Python 3.10 or later. You have installed RHEL 8.6 or later. You registered your system with Red Hat Subscription Manager. Note Ensure that you only install the navigator matching your current Red Hat Ansible Automation Platform environment. Procedure Attach the Red Hat Ansible Automation Platform SKU: USD subscription-manager attach --pool=<sku-pool-id> Install automation content navigator with the following command: v.2.4 for RHEL 8 for x86_64 USD sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-8-x86_64-rpms ansible-navigator v.2.4 for RHEL 9 for x86-64 USD sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-navigator Verification Verify your automation content navigator installation: USD ansible-navigator --help The following example demonstrates a successful installation:

Commands:
subscription-manager attach --pool=<sku-pool-id>
sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-8-x86_64-rpms ansible-navigator
sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-navigator
ansible-navigator --help
Chapter 19. Near Caching Near caches are optional caches for Hot Rod Java client implementations that keep recently accessed data close to the user, providing faster access to data that is accessed frequently. This cache acts as a local Hot Rod client cache that is updated whenever a remote entry is retrieved via get or getVersioned operations. In Red Hat JBoss Data Grid, near cache consistency is achieved by using remote events, which send notifications to clients when entries are modified or removed (refer to Section 7.7, "Remote Event Listeners (Hot Rod)" ). With Near Caching, local cache remains consistent with remote cache. Local entry is updated or invalidated whenever remote entry on the server is updated or removed. At the client level, near caching is configurable as either Lazy or Eager modes, which is determined by the user when enabling near caching. Note Near caching is disabled for Hot Rod clients by default. Figure 19.1. Near Caching Architecture Report a bug 19.1. Lazy and Eager Near Caches Lazy Near Cache Entries are only added to lazy near caches when they are received remotely via get or getVersioned . If a cache entry is modified or removed on the server side, the Hot Rod client receives the events, which then invalidate the near cache entries by removing them from the near cache. This is an efficient way of maintaining near cache consistency as the events sent back to the client only contain key information. However, if a cache entry is retrieved after being modified the Hot Rod client must then retrieve it from the remote server. Eager Near Cache Eager near caches are eagerly populated as entries are created on the server. When entries are modified, the latest value is sent along with the notification to the client, which stores it in the near cache. Eager caches are also populated when an entry is retrieved remotely, provided it is not already present. Eager near caches have the advantage of reducing the cost of accessing the server by having newly created entries present in the near cache before requests to retrieve them are received. Eager near caches also allow modified entries that are re-queried by the client to be fetched directly from the near cache. The drawback of using eager near caching is that events received from the server are larger in size due to shipping value information, and entries may be sent to the client that will not be queried. Warning Although the eager near caching setting is provided, it is not supported for production use, as with high number of events, value sizes, or clients, eager near caching can generate a large amount of network traffic and potentially overload clients. For production use, it is recommended to use lazy near caches instead. Report a bug

Commands:
Chapter 3. Block pools The OpenShift Data Foundation operator installs a default set of storage pools depending on the platform in use. These default storage pools are owned and controlled by the operator and it cannot be deleted or modified. With OpenShift Container Platform, you can create multiple custom storage pools which map to storage classes that provide the following features: Enable applications with their own high availability to use persistent volumes with two replicas, potentially improving application performance. Save space for persistent volume claims using storage classes with compression enabled. Note Multiple block pools are not supported for external mode OpenShift Data Foundation clusters. 3.1. Creating a block pool Prerequisites You must be logged into the OpenShift Container Platform web console as an administrator. Procedure Click Storage Data Foundation . In the Storage systems tab, select the storage system and then click the BlockPools tab. Click Create Block Pool . Enter Pool name . Note Using 2-way replication data protection policy is not supported for the default pool. However, you can use 2-way replication if you are creating an additional pool. Select Data protection policy as either 2-way Replication or 3-way Replication . Select Volume Type . Optional: Select Enable compression checkbox if you need to compress the data. Enabling compression can impact application performance and might prove ineffective when data to be written is already compressed or encrypted. Data written before enabling compression will not be compressed. Click Create . 3.2. Updating an existing pool Prerequisites You must be logged into the OpenShift Container Platform web console as an administrator. Procedure Click Storage Data Foundation . In the Storage systems tab, select the storage system and then click BlockPools . Click the Action Menu (...) at the end the pool you want to update. Click Edit Block Pool . Modify the form details as follows: Note Using 2-way replication data protection policy is not supported for the default pool. However, you can use 2-way replication if you are creating an additional pool. Change the Data protection policy to either 2-way Replication or 3-way Replication. Enable or disable the compression option. Enabling compression can impact application performance and might prove ineffective when data to be written is already compressed or encrypted. Data written before enabling compression will not be compressed. Click Save . 3.3. Deleting a pool Use this procedure to delete a pool in OpenShift Data Foundation. Prerequisites You must be logged into the OpenShift Container Platform web console as an administrator. Procedure . Click Storage Data Foundation . In the Storage systems tab, select the storage system and then click the BlockPools tab. Click the Action Menu (...) at the end the pool you want to delete. Click Delete Block Pool . Click Delete to confirm the removal of the Pool. Note A pool cannot be deleted when it is bound to a PVC. You must detach all the resources before performing this activity.

Commands:
8.3.5. Anticipating Your Future Needs Depending upon your target and resources, there are many tools available. There are tools for wireless networks, Novell networks, Windows systems, Linux systems, and more. Another essential part of performing assessments may include reviewing physical security, personnel screening, or voice/PBX network assessment. New concepts, such as war walking - scanning the perimeter of your enterprise's physical structures for wireless network vulnerabilities - are some emerging concepts that you can investigate and, if needed, incorporate into your assessments. Imagination and exposure are the only limits of planning and conducting vulnerability assessments.

Commands:
Chapter 1. Introduction This document describes how to configure Red Hat OpenStack Platform to use a Fujitsu ETERNUS Disk Storage System as a back end for the Block Storage service. The document covers how to define a Fibre Channel and iSCSI back end provided by an ETERNUS device on an overcloud deployment. This process involves defining both back ends as a custom back end for the Block Storage service. By default, Controller nodes contain the Block Storage service. Prerequisites You intend to use only Fujitsu ETERNUS Disk Storage System devices and drivers for Block Storage back ends. You can use the director installation user , that you create with the overcloud deployment. For more information about creating the stack user, see Preparing the undercloud in the Director Installation and Usage guide. You have access to an Admin account on the ETERNUS device through the ETERNUS Web GUI or CLI. Red Hat supports using Fibre Channel or iSCSI interfaces, and the respective drivers and settings, with a Fujitsu ETERNUS device. Note For more information about defining a custom back end, see the Custom Block Storage Back End Deployment Guide .

Commands: