mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Features The features added in this release, and that were not in releases of AMQ Streams, are outlined below. Note To view all the enhancements and bugs that are resolved in this release, see the AMQ Streams Jira project . 1.1. Kafka 2.7.0 support AMQ Streams now supports Apache Kafka version 2.7.0. AMQ Streams uses Kafka 2.7.0. Only Kafka distributions built by Red Hat are supported. For upgrade instructions, see AMQ Streams and Kafka upgrades . Refer to the Kafka 2.6.0 and Kafka 2.7.0 Release Notes for additional information. Note Kafka 2.6.x is supported only for the purpose of upgrading to AMQ Streams 1.7. For more information on supported versions, see the Red Hat Knowledgebase article Red Hat AMQ 7 Component Details Page . Kafka 2.7.0 requires the same ZooKeeper version as Kafka 2.6.x (ZooKeeper version 3.5.8). Therefore, you do not need to upgrade ZooKeeper when upgrading from AMQ Streams 1.6 to AMQ Streams 1.7.

Commands:
8.3.3. Reverting and Repeating Transactions Apart from reviewing the transaction history, the yum history command provides means to revert or repeat a selected transaction. To revert a transaction, type the following at a shell prompt as root : yum history undo id To repeat a particular transaction, as root , run the following command: yum history redo id Both commands also accept the last keyword to undo or repeat the latest transaction. Note that both yum history undo and yum history redo commands only revert or repeat the steps that were performed during a transaction. If the transaction installed a new package, the yum history undo command will uninstall it, and if the transaction uninstalled a package the command will again install it. This command also attempts to downgrade all updated packages to their version, if these older packages are still available. When managing several identical systems, Yum also allows you to perform a transaction on one of them, store the transaction details in a file, and after a period of testing, repeat the same transaction on the remaining systems as well. To store the transaction details to a file, type the following at a shell prompt as root : yum -q history addon-info id saved_tx > file_name Once you copy this file to the target system, you can repeat the transaction by using the following command as root : yum load-transaction file_name Note, however that the rpmdb version stored in the file must be identical to the version on the target system. You can verify the rpmdb version by using the yum version nogroups command.

Commands:
Chapter 1. Debezium Overview Red Hat build of Debezium is a distributed platform that captures database operations, creates data change event records for row-level operations, and streams change event records to Apache Kafka topics. Debezium is built on Apache Kafka and is deployed and integrated with Streams for Apache Kafka. Debezium captures row-level changes to a database table and passes corresponding change events to Streams for Apache Kafka. Applications can read these change event streams and access the change events in the order in which they occurred. Debezium is the upstream community project for Red Hat build of Debezium. Debezium has multiple uses, including: Data replication Updating caches and search indexes Simplifying monolithic applications Data integration Enabling streaming queries Debezium provides Apache Kafka Connect connectors for the following common databases: Db2 MariaDB MySQL MongoDB Oracle PostgreSQL SQL Server

Commands:
Chapter 1. Overview Red Hat OpenShift Data Foundation is software-defined storage that is optimized for container environments. It runs as an operator on OpenShift Container Platform to provide highly integrated and simplified persistent storage management for containers. Red Hat OpenShift Data Foundation is integrated into the latest Red Hat OpenShift Container Platform to address platform services, application portability, and persistence challenges.It provides a highly scalable backend for the generation of cloud-native applications, built on a technology stack that includes Red Hat Ceph Storage, the Rook.io Operator, and NooBaa's Multicloud Object Gateway technology. Red Hat OpenShift Data Foundation is designed for FIPS. When running on RHEL or RHEL CoreOS booted in FIPS mode, OpenShift Container Platform core components use the RHEL cryptographic libraries submitted to NIST for FIPS Validation on only the x86_64, ppc64le, and s390X architectures. For more information about the NIST validation program, see Cryptographic Module Validation Program . For the latest NIST status for the individual versions of the RHEL cryptographic libraries submitted for validation, see Compliance Activities and Government Standards . Red Hat OpenShift Data Foundation provides a trusted, enterprise-grade application development environment that simplifies and enhances the user experience across the application lifecycle in a number of ways: Provides block storage for databases. Shared file storage for continuous integration, messaging, and data aggregation. Object storage for cloud-first development, archival, backup, and media storage. Scale applications and data exponentially. Attach and detach persistent data volumes at an accelerated rate. Stretch clusters across multiple data-centers or availability zones. Establish a comprehensive application container registry. Support the generation of OpenShift workloads such as Data Analytics, Artificial Intelligence, Machine Learning, Deep Learning, and Internet of Things (IoT). Dynamically provision not only application containers, but data service volumes and containers, as well as additional OpenShift Container Platform nodes, Elastic Block Store (EBS) volumes and other infrastructure services. 1.1. About this release Red Hat OpenShift Data Foundation 4.14 ( RHSA-2023:6832 ) is now available. New enhancements, features, and known issues that pertain to OpenShift Data Foundation 4.14 are included in this topic. Red Hat OpenShift Data Foundation 4.14 is supported on the Red Hat OpenShift Container Platform version 4.14. For more information, see Red Hat OpenShift Data Foundation Supportability and Interoperability Checker . For Red Hat OpenShift Data Foundation life cycle information, refer to the layered and dependent products life cycle section in Red Hat OpenShift Container Platform Life Cycle Policy .

Commands:
3.2.2. RT Tunable Parameters The RT scheduler works in a similar way to the ceiling enforcement control of the CFS (for more information, refer to Section 3.2.1, "CFS Tunable Parameters" ) but limits CPU access to real-time tasks only. The amount of time for which real-time task can access the CPU is decided by allocating a run time and a period for each cgroup. All tasks in a cgroup are then allowed to access the CPU for the defined period of time for one run time (for example, tasks in a cgroup can be allowed to run 0.1 seconds in every 1 second). Please note that the following parameters take into account all available logical CPUs, therefore the access times specified with these parameters are in fact multiplied by the number of CPUs. cpu.rt_period_us applicable to real-time scheduling tasks only, this parameter specifies a period of time in microseconds (ms, represented here as " us ") for how regularly a cgroup's access to CPU resources is reallocated. cpu.rt_runtime_us applicable to real-time scheduling tasks only, this parameter specifies a period of time in microseconds (ms, represented here as " us ") for the longest continuous period in which the tasks in a cgroup have access to CPU resources. Establishing this limit prevents tasks in one cgroup from monopolizing CPU time. As mentioned above, the access times are multiplied by the number of logical CPUs. For example, setting cpu.rt_runtime_us to 200000 and cpu.rt_period_us to 1000000 translates to the task being able to access a single CPU for 0.4 seconds out of every 1 second on systems with two CPUs (0.2 x 2), or 0.8 seconds on systems with four CPUs (0.2 x 4).

Commands:
Chapter 12. NodeMetrics [metrics.k8s.io/v1beta1] Description NodeMetrics sets resource usage metrics of a node. Type object Required timestamp window usage 12.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata ObjectMeta Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata timestamp Time The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. usage object (Quantity) The memory usage is the memory working set. window Duration 12.2. API endpoints The following API endpoints are available: /apis/metrics.k8s.io/v1beta1/nodes GET : list objects of kind NodeMetrics /apis/metrics.k8s.io/v1beta1/nodes/{name} GET : read the specified NodeMetrics 12.2.1. /apis/metrics.k8s.io/v1beta1/nodes HTTP method GET Description list objects of kind NodeMetrics Table 12.1. HTTP responses HTTP code Reponse body 200 - OK NodeMetricsList schema 12.2.2. /apis/metrics.k8s.io/v1beta1/nodes/{name} Table 12.2. Global path parameters Parameter Type Description name string name of the NodeMetrics HTTP method GET Description read the specified NodeMetrics Table 12.3. HTTP responses HTTP code Reponse body 200 - OK NodeMetrics schema

Commands:
9.3. Payment Card Industry Data Security Standard (PCI DSS) From https://www.pcisecuritystandards.org/ : The PCI Security Standards Council is an open global forum, launched in 2006, that is responsible for the development, management, education, and awareness of the PCI Security Standards, including the Data Security Standard (DSS). You can download the PCI DSS standard from https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml .

Commands:
Appendix B. Applying custom configuration to Red Hat Satellite When you install and configure Satellite for the first time using satellite-installer , you can specify that the DNS and DHCP configuration files are not to be managed by Puppet using the installer flags --foreman-proxy-dns-managed=false and --foreman-proxy-dhcp-managed=false . If these flags are not specified during the initial installer run, rerunning of the installer overwrites all manual changes, for example, rerun for upgrade purposes. If changes are overwritten, you must run the restore procedure to restore the manual changes. For more information, see Restoring Manual Changes Overwritten by a Puppet Run . To view all installer flags available for custom configuration, run satellite-installer --scenario satellite --full-help . Some Puppet classes are not exposed to the Satellite installer. To manage them manually and prevent the installer from overwriting their values, specify the configuration values by adding entries to configuration file /etc/foreman-installer/custom-hiera.yaml . This configuration file is in YAML format, consisting of one entry per line in the format of <puppet class>::<parameter name>: <value> . Configuration values specified in this file persist across installer reruns. Common examples include: For Apache, to set the ServerTokens directive to only return the Product name: To turn off the Apache server signature entirely: The Puppet modules for the Satellite installer are stored under /usr/share/foreman-installer/modules . Check the .pp files (for example: moduleName /manifests/ example .pp) to look up the classes, parameters, and values. Alternatively, use the grep command to do keyword searches. Setting some values may have unintended consequences that affect the performance or functionality of Red Hat Satellite. Consider the impact of the changes before you apply them, and test the changes in a non-production environment first. If you do not have a non-production Satellite environment, run the Satellite installer with the --noop and --verbose options. If your changes cause problems, remove the offending lines from custom-hiera.yaml and rerun the Satellite installer. If you have any specific questions about whether a particular value is safe to alter, contact Red Hat support.

Commands:
apache::server_tokens: Prod
apache::server_signature: Off
Migrating to Red Hat build of Apache Camel for Spring Boot Red Hat build of Apache Camel 4.8 Migrating to Red Hat build of Apache Camel for Spring Boot Red Hat build of Apache Camel Documentation Team fuse-docs-support@redhat.com Red Hat build of Apache Camel Support Team http://access.redhat.com/support

Commands:
camel.springboot.stream-caching-spool-enabled=true
<circuitBreaker> <resilience4jConfiguration> <timeoutEnabled>true</timeoutEnabled> <timeoutDuration>2000</timeoutDuration> </resilience4jConfiguration> </circuitBreaker>
<circuitBreaker> <resilience4jConfiguration timeoutEnabled="true" timeoutDuration="2000"/> </circuitBreaker>
<route id="myRoute"> <description>Something that this route do</description> <from uri="kafka:cheese"/> </route>
<route id="myRoute" description="Something that this route do"> <from uri="kafka:cheese"/> </route>
<dependency> <groupId>org.apache.camel.springbboot</groupId> <artifactId>camel-xml-io-dsl-starter</artifactId> <version>{CamelSBProjectVersion}</version> </dependency>
camel.health.producers-enabled = true
- route: from: uri: "direct:info" steps: - log: "message"
- route: from: uri: "direct:info" steps: - log: "message"
"bean:myBean?method=foo(com.foo.MyOrder.class, true)"
"bean:myBean?method=bar(String.class, int.class)"
<camelContext id="SampleCamel" xmlns="http://camel.apache.org/schema/spring"> <restConfiguration port="8080" bindingMode="off" scheme="http" contextPath="myapi" apiContextPath="myapi/swagger"> </restConfiguration>
@SpringBootApplication(exclude = RestConfigurationDefinitionAutoConfiguration.class) // load the spring xml file from classpath @ImportResource("classpath:my-camel.xml") public class SampleCamelApplication {
from("platform-http:myservice") .to("...")
<dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-core</artifactId> <version>2.3.0.1</version> </dependency> <dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-impl</artifactId> <version>2.3.2</version> </dependency>
2015-01-12 13:23:23,656 [- ShutdownTask] INFO DefaultShutdownStrategy - There are 1 inflight exchanges: InflightExchange: [exchangeId=ID-test-air-62213-1421065401253-0-3, fromRouteId=route1, routeId=route1, nodeId=delay1, elapsed=2007, duration=2017]
context.getShutdownStrategegy().setLogInflightExchangesOnTimeout(false);
telegram:bots/myTokenHere
telegram:bots?authorizationToken=myTokenHere
ManagedCamelContext managed = camelContext.getExtension(ManagedCamelContext.class);
Chapter 18. complete.adoc This chapter describes the commands under the complete.adoc command. 18.1. complete print bash completion command Usage: Table 18.1. Optional Arguments Value Summary -h, --help Show this help message and exit --name <command_name> Command name to support with command completion --shell <shell> Shell being used. use none for data only (default: bash)

Commands:
openstack complete [-h] [--name <command_name>] [--shell <shell>]
8.39. fcoe-target-utils 8.39.1. RHBA-2013:1683 - fcoe-target-utils bug fix update Updated fcoe-target-utils packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The fcoe-target-utils packages contain a command-line interface for configuring FCoE LUNs (Fibre Channel over Ethernet Logical Unit Numbers) and backstores. Bug Fixes BZ# 854708 Due to an error leaving a device marked as in-use, attempts to map a block backstore that had been previously mapped would fail. With this update, mappings of block backstores are properly released, and remapping a block device now succeeds. BZ# 880542 Prior to this update, the kernel terminated unexpectedly when the fcoe-target daemon stopped. A patch has been provided to fix this bug, and the kernel now no longer crashes. BZ# 882121 Previously, the target reported support for sequence-level error recovery erroneously. Consequently, interrupting the connection between the FCoE target and a bnx2fc initiator could cause the initiator to erroneously perform sequence-level error recovery instead of exchange-level error, leading to a failure of all devices attached to the target. This bug has been fixed, and connections with a bnx2fc initiator may now be interrupted without disrupting other devices. BZ# 912210 Prior to this update, there was an error in the python-rtslib library. Consequently, when creating a pscsi (SCSI pass-through) storage object in the targetcli utility, the python-rtslib returned a traceback. The error in the library has been fixed, and pscsi storage objects are now created without errors. BZ# 999902 Since the fcoe-utils command-line interface is required by the fcoe-target-utils packages and is not supported on the s390x architecture, fcoe-target-utils will not work properly on s390x, and thus has been removed. Users of fcoe-target-utils are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 1. Compatibility Matrix for Red Hat Ceph Storage 4.0 The following tables list products and their versions compatible with Red Hat Ceph Storage 4.0. Host Operating System Version Notes Red Hat Enterprise Linux 7.7 and 8.1 Included in the product Important All nodes in the cluster and their clients must use the supported OS version(s) to ensure that the version of the ceph package is the same on all nodes. Using different versions of the ceph package is not supported. Important Red Hat no longer supports using Ubuntu as a host operating system to deploy Red Hat Ceph Storage. Product Version Notes Ansible 2.8 Included in the product Red Hat OpenShift 3.0 and later 3.x versions The RBD driver is supported starting with version 3.0 and Cinder driver is supported starting with version 3.1. Red Hat OpenShift 4 is not supported. Red Hat OpenStack Platform 13, 15 and 16 Red Hat OpenStack Platform 11, 12 and 14 is not supported. Red Hat OpenStack Platform 10 and Red Hat Ceph Storage 4 are not a tested combination. Director 13 deployed Red Hat Ceph Storage 3.1+ also supports external Red Hat Ceph Storage 4. Director 16 deployed Red Hat Ceph Storage 4.0 also supports external Red Hat Ceph Storage 5. Red Hat Satellite 6.x Only registering with the Content Delivery Network (CDN) is supported. Registering with Red Hat Network (RHN) is deprecated and not supported. Client Connector Version Notes S3A 2.8.x, 3.2.x, and trunk Red Hat Enterprise Linux iSCSI Initiator The latest versions of the iscsi-initiator-utils and device-mapper-multipath packages RHCS as a backup target Version Notes CommVault Cloud Data Management v11 IBM Spectrum Protect Plus 10.1.5 IBM Spectrum Protect server 8.1.8 NetApp AltaVault 4.3.2 and 4.4 Rubrik Cloud Data Management (CDM) 3.2 and later Trilio, TrilioVault 3.0 S3 target Veeam (object storage) Veeam Availability Suite 9.5 Update 4 Supported on Red Hat Ceph Storage object storage with the S3 protocol Veritas NetBackup for Symantec OpenStorage (OST) cloud backup 7.7 and 8.0 Independent Software vendors Version Notes IBM Spectrum Discover 2.0.3

Commands:
4.9. Configuring Headless Virtual Machines You can configure a headless virtual machine when it is not necessary to access the machine via a graphical console. This headless machine will run without graphical and video devices. This can be useful in situations where the host has limited resources, or to comply with virtual machine usage requirements such as real-time virtual machines. Headless virtual machines can be administered via a Serial Console, SSH, or any other service for command line access. Headless mode is applied via the Console tab when creating or editing virtual machines and machine pools, and when editing templates. It is also available when creating or editing instance types. If you are creating a new headless virtual machine, you can use the Run Once window to access the virtual machine via a graphical console for the first run only. See Virtual Machine Run Once settings explained for more details. Prerequisites If you are editing an existing virtual machine, and the Red Hat Virtualization guest agent has not been installed, note the machine's IP prior to selecting Headless Mode . Before running a virtual machine in headless mode, the GRUB configuration for this machine must be set to console mode otherwise the guest operating system's boot process will hang. To set console mode, comment out the spashimage flag in the GRUB menu configuration file: #splashimage=(hd0,0)/grub/splash.xpm.gz serial --unit=0 --speed=9600 --parity=no --stop=1 terminal --timeout=2 serial Note Restart the virtual machine if it is running when selecting the Headless Mode option. Configuring a Headless Virtual Machine Click Compute Virtual Machines and select a virtual machine. Click Edit . Click the Console tab. Select Headless Mode . All other fields in the Graphical Console section are disabled. Optionally, select Enable VirtIO serial console to enable communicating with the virtual machine via serial console. This is highly recommended. Reboot the virtual machine if it is running. See Rebooting a Virtual Machine .

Commands:
#splashimage=(hd0,0)/grub/splash.xpm.gz serial --unit=0 --speed=9600 --parity=no --stop=1 terminal --timeout=2 serial
14.13.4. Displaying Information about the Virtual CPU Counts of a Domain virsh vcpucount requires a domain name or a domain ID. For example: The vcpucount can take the following options: --maximum displays the maximum number of vCPUs available --active displays the number of currently active vCPUs --live displays the value from the running domain --config displays the value to be configured on guest virtual machine's boot --current displays the value according to current domain state --guest displays the count that is returned is from the perspective of the guest

Commands:
virsh vcpucount rhel6 maximum config 2 maximum live 2 current config 2 current live 2