mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Key features AMQ Streams simplifies the process of running Apache Kafka in an OpenShift cluster. This guide is intended as a starting point for building an understanding of AMQ Streams. The guide introduces some of the key concepts behind Kafka, which is central to AMQ Streams, explaining briefly the purpose of Kafka components. Configuration points are outlined, including options to secure and monitor Kafka. A distribution of AMQ Streams provides the files to deploy and manage a Kafka cluster, as well as example files for configuration and monitoring of your deployment . A typical Kafka deployment is described, as well as the tools used to deploy and manage Kafka. 1.1. Kafka capabilities The underlying data stream-processing capabilities and component architecture of Kafka can deliver: Microservices and other applications to share data with extremely high throughput and low latency Message ordering guarantees Message rewind/replay from data storage to reconstruct an application state Message compaction to remove old records when using a key-value log Horizontal scalability in a cluster configuration Replication of data to control fault tolerance Retention of high volumes of data for immediate access 1.2. Kafka use cases Kafka's capabilities make it suitable for: Event-driven architectures Event sourcing to capture changes to the state of an application as a log of events Message brokering Website activity tracking Operational monitoring through metrics Log collection and aggregation Commit logs for distributed systems Stream processing so that applications can respond to data in real time 1.3. How AMQ Streams supports Kafka AMQ Streams provides container images and Operators for running Kafka on OpenShift. AMQ Streams Operators are fundamental to the running of AMQ Streams. The Operators provided with AMQ Streams are purpose-built with specialist operational knowledge to effectively manage Kafka. Operators simplify the process of: Deploying and running Kafka clusters Deploying and running Kafka components Configuring access to Kafka Securing access to Kafka Upgrading Kafka Managing brokers Creating and managing topics Creating and managing users

Commands:
Chapter 3. Accessing the registry In Red Hat OpenShift Service on AWS, Red Hat Site Reliability Engineering (SRE) manages the registry for you. However, you can check the status of the registry pods and view the registry logs. 3.1. Checking the status of the registry pods As an administrator with the dedicated-admin role, you can list the image registry pods running in the openshift-image-registry project and check their status. Prerequisites You have access to the cluster as a user with the dedicated-admin role. Procedure List the pods in the openshift-image-registry project and view their status: USD oc get pods -n openshift-image-registry Example output NAME READY STATUS RESTARTS AGE image-registry-79fb4469f6-llrln 1/1 Running 0 77m node-ca-hjksc 1/1 Running 0 73m node-ca-tftj6 1/1 Running 0 77m node-ca-wb6ht 1/1 Running 0 77m node-ca-zvt9q 1/1 Running 0 74m 3.2. Viewing registry logs You can view the logs for the registry by using the oc logs command. Procedure Use the oc logs command with deployments to view the logs for the container image registry: USD oc logs deployments/image-registry -n openshift-image-registry Example output 2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown" 2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler" 2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

Commands:
oc get pods -n openshift-image-registry
NAME READY STATUS RESTARTS AGE image-registry-79fb4469f6-llrln 1/1 Running 0 77m node-ca-hjksc 1/1 Running 0 73m node-ca-tftj6 1/1 Running 0 77m node-ca-wb6ht 1/1 Running 0 77m node-ca-zvt9q 1/1 Running 0 74m
oc logs deployments/image-registry -n openshift-image-registry
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown" 2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler" 2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
Chapter 11. Getting started with kernel logging Log files provide messages about the system, including the kernel, services, and applications running on it. The logging system in Red Hat Enterprise Linux is provided by the built-in syslog protocol. Various utilities use this system to record events and organize them into log files. These files are useful when auditing the operating system or troubleshooting problems. 11.1. What is the kernel ring buffer During the boot process, the console provides important information about the initial phase of the system startup. To avoid loss of the early messages the kernel utilizes a ring buffer. This buffer stores all messages, including boot messages, generated by the printk() function within the kernel code. The messages from the kernel ring buffer are then read and stored in log files on permanent storage, for example, by the syslog service. The ring buffer is a cyclic data structure that has a fixed size, and is hard-coded into the kernel. Users can display data stored in the kernel ring buffer through the dmesg command or the /var/log/boot.log file. When the ring buffer is full, the new data overwrites the old. Additional resources syslog(2) and dmesg(1) manual page 11.2. Role of printk on log-levels and kernel logging Each message the kernel reports has a log-level associated with it that defines the importance of the message. The kernel ring buffer, as described in What is the kernel ring buffer , collects kernel messages of all log-levels. It is the kernel.printk parameter that defines what messages from the buffer are printed to the console. The log-level values break down in this order: 0 Kernel emergency. The system is unusable. 1 Kernel alert. Action must be taken immediately. 2 Condition of the kernel is considered critical. 3 General kernel error condition. 4 General kernel warning condition. 5 Kernel notice of a normal but significant condition. 6 Kernel informational message. 7 Kernel debug-level messages. By default, kernel.printk in RHEL 9 has the following values: The four values define the following, in order: Console log-level, defines the lowest priority of messages printed to the console. Default log-level for messages without an explicit log-level attached to them. Sets the lowest possible log-level configuration for the console log-level. Sets default value for the console log-level at boot time. Each of these values defines a different rule for handling error messages. Important The default 7 4 1 7 printk value allows for better debugging of kernel activity. However, when coupled with a serial console, this printk setting might cause intense I/O bursts that might lead to a RHEL system becoming temporarily unresponsive. To avoid these situations, setting a printk value of 4 4 1 7 typically works, but at the expense of losing the extra debugging information. Also note that certain kernel command line parameters, such as quiet or debug , change the default kernel.printk values. Additional resources syslog(2) manual page

Commands:
sysctl kernel.printk kernel.printk = 7 4 1 7
2.27. RHEA-2011:0640 - new package: perl-Term-ProgressBar A new perl-Term-ProgressBar package is now available for Red Hat Enterprise Linux 6. The Term::ProgressBar module provides a mechanism for Perl scripts to display a progress bar on the command line. This enhancement update adds the perl-Term-ProgressBar package to Red Hat Enterprise Linux 6. (BZ# 665417 ) All users who require the Term::ProgressBar Perl module should install this new package.

Commands:
8.176. Red Hat Enterprise Linux 6.5 Release Notes 8.176.1. RHEA-2013:1717 - Red Hat Enterprise Linux 6.5 Release Notes Updated packages containing the Release Notes for Red Hat Enterprise Linux 6.5 are now available. Red Hat Enterprise Linux minor releases are an aggregation of individual enhancement, security and bug fix errata. The Red Hat Enterprise Linux 6.5 Release Notes documents the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release. Detailed notes on all changes in this minor release are available in the Technical Notes. Refer to the Online Release Notes for the most up-to-date version of the Red Hat Enterprise Linux 6.5 Release Notes: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux /6/html-single/6.5_Release_Notes/index.html

Commands:
Chapter 7. Invoking functions You can test a deployed function by invoking it. You can do it using the kn func tool. 7.1. Invoking a deployed function with a test event You can use the kn func invoke CLI command to send a test request to invoke a function either locally or on your OpenShift Container Platform cluster. You can use this command to test that a function is working and able to receive events correctly. Invoking a function locally is useful for a quick test during function development. Invoking a function on the cluster is useful for testing that is closer to the production environment. Prerequisites The OpenShift Serverless Operator and Knative Serving are installed on the cluster. You have installed the Knative ( kn ) CLI. You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform. You must have already deployed the function that you want to invoke. Procedure Invoke a function: USD kn func invoke The kn func invoke command only works when there is either a local container image currently running, or when there is a function deployed in the cluster. The kn func invoke command executes on the local directory by default, and assumes that this directory is a function project.

Commands:
kn func invoke
2.3. RHEA-2011:0644 - new package: biosdevname A new biosdevname package is now available for Red Hat Enterprise Linux 6. Traditionally, network interfaces in Linux are named eth[X]. However, in many cases, these names do not correspond to actual labels on the chassis. Modern server platforms with multiple network adapters can encounter non-deterministic and counter-intuitive naming of these network interfaces. This update for Red Hat Enterprise Linux 6 introduces biosdevname, an optional convention for naming network interfaces. biosdevname assigns names to network interfaces based on their physical location. Note that biosdevname is disabled by default, except for a limited set of Dell PowerEdge, C Series and Precision Workstation systems. Further information on the new biosdevname feature is available in this Knowledgebase article .

Commands:
7. Installation Installation and boot support is added in Red Hat Enterprise Linux 6.1 for the Emulex 10GbE PCI-E Gen2 and Chelsio T4 10GbE network adapters. Additionally, the GRUB bootloader is updated with support for booting volumes with a 4KB sector size on UEFI systems. The installer in Red Hat Enterprise Linux 6.1 will detect unsupported hardware platforms and provide a notification to the user. The installation will continue, but the following message is displayed Improved support for iSCSI adapters Red Hat Enterprise Linux 6.1 features improved support for iSCSI adapters at installation and boot time, including the ability to separate login credentials for iSCSI storage during installation and support for offload iSCSI adapters (e.g. the Emulex Tiger Shark adapter). Red Hat Enterprise Linux 6 supports installation over iSCSI using auto-detection of BIOS iSCSI settings in iBFT. However, reconfiguration of the iBFT settings after installation was not possible. In Red Hat enterprise Linux 6.1, TCP/IP settings and iSCSI initiator configuration are dynamically configured from iBFT settings during boot time.

Commands:
This hardware (or a combination thereof) is not supported by Red Hat. For more information on supported hardware, please refer to http://www.redhat.com/hardware.
Chapter 6. Known issues Sometimes a Cryostat release might contain an issue or issues that Red Hat acknowledges and might fix at a later stage during the product's development. Review each known issue for its description and its resolution. Cryostat agent reports a "Boot class path mechanism is unsupported" warning message Description The Cryostat agent reports a "Boot class path mechanism is unsupported" warning message in the error log. This message occurs when the Cryostat agent tries to gather information about the host Java Virtual Machine (JVM) and encounters the "boot class path mechanism" attribute, which is not supported by the JVM. This attribute is supported in OpenJDK versions 9 and earlier only, however, the Cryostat agent is supported from OpenJDK version 11. Therefore, because this attribute is attached to JVMs where it is not supported, an exception is flagged and appears in the error log as a warning. Workaround No action is required.

Commands:
Chapter 4. Changing the language by using desktop GUI This section describes how to change the system language using the desktop GUI. Prerequisites Required language packages are installed on your system Procedure Open the Settings application from the system menu by clicking on its icon. In Settings , choose Region & Language from the left side bar. Click the Language menu. Select the required region and language from the menu. If your region and language are not listed, scroll down, and click More to select from available regions and languages. Click Done . Click Restart for changes to take effect. Note Some applications do not support certain languages. The text of an application that cannot be translated into the selected language remains in US English. Additional resources Launching applications in GNOME

Commands:
2.4. Increase the Maximum Number of Cached Instances JBoss Data Virtualization maintains a pool of extra socket connections that are reused. For load balancing, this reduces the potential cost of switching a connection to another server instance. The default setting is to maintain 16 connections. If the client application is connecting to a large number of JBoss Data Virtualization instances and post connection time load balancing is used, then consider increasing the number of cached instances. Procedure 2.1. Increase the Maximum Number of Cached Instances Increase the org.teiid.sockets.maxCachedInstances property in the teiid-client-settings.properties file located in EAP_HOME /dataVirtualization/jdbc/teiid- VERSION -redhat- N -jdbc.jar . Note An example file ( teiid-client-settings.orig.properties ) is packaged in the client JAR file.

Commands:
4.207. openscap 4.207.1. RHBA-2011:1618 - openscap bug fix and enhancement update Updated openscap packages that fix various bugs and add several enhancements are now available for Red Hat Enterprise Linux 6. The Security Content Automation Protocol (SCAP) is a line of standards that provide a standard language for the expression of Computer Network Defense (CND) related information. OpenSCAP is a set of open source libraries for the integration of SCAP. The openscap packages have been upgraded to upstream version 0.8.0, which provides a number of bug fixes and enhancements over the version. The most important changes include support for Open Vulnerability and Assessment Language (OVAL) version 5.8. (BZ# 697648 ) All users of openscap are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
2.2. Other changes to Red Hat JBoss Data Virtualization Week Function Red Hat JBoss Data Virtualization now consistently returns the ISO 8601 standard for WEEK statements. Previously, locale was used for many databases. This change can potentially break functionality for users of databases such as H2, Microsoft SQL Server, and Sybase. Avoid using locale with these databases. ibm.jdk Dependency is Missing From the org.jboss.security.negotiation Module The ibm.jdk dependency is not present in the org.jboss.security.negotiation module, nor is it in the patched version in the .overlay directory. You must copy this dependency into the directory every time you patch the Red Hat JBoss Enterprise Application Platform. UDF Functions Definition Model The UDF Function Definitions model is no longer supported. To avoid compatibility problems, rebuild any models you created with it.

Commands:
Chapter 8. MBean counter types The MBean counter types that you can specify as part of a custom trigger definition are standard MBean metrics that are generally available in the JDK by default. These MBean counters cover a range of runtime, memory, thread, and operating system metrics. The following is a full list of the MBean counter types that you can specify in a custom trigger definition: Note The name of each MBean counter that you specify as part of a custom trigger definition must exactly match the spelling and capitalization of the MBean counter names in the following list. Operating system metrics Arch AvailableProcessors Name SystemLoadAverage Version CommittedVirtualMemorySize FreePhysicalMemorySize FreeSwapSpaceSize ProcessCpuLoad ProcessCpuTime SystemCpuLoad TotalPhysicalMemorySize TotalSwapSpaceSize Thread metrics AllThreadIds CurrentThreadCpuTime CurrentThreadUserTime DaemonThreadCount PeakThreadCount ThreadCount TotalStartedThreadCount CurrentThreadCpuTimeSupported ObjectMonitorUsageSupported SynchronizerUsageSupported ThreadContentionMonitoringEnabled ThreadContentionMonitoringSupported ThreadCpuTimeEnabled ThreadCpuTimeSupported Runtime metrics BootClassPathSupported BootClassPath ClassPath InputArguments LibraryPath ManagementSpecVersion Name SpecName SpecVersion SystemProperties StartTime Uptime VmName VmVendor VmVersion Memory metrics HeapMemoryUsage NonHeapMemoryUsage ObjectPendingFinalizationCount FreeHeapMemory FreeNonHeapMemory HeapMemoryUsagePercent Verbose Revised on 2024-07-02 13:36:03 UTC

Commands:
Chapter 2. New features This section describes new features introduced in Red Hat OpenShift Data Foundation 4.17. 2.1. Disaster recovery solution 2.1.1. Disabling DR for a given workload Disaster recovery (DR) can be disabled for a given workload for managed applications and discovered applications through the OpenShift Web Console. For more information, see Disabling disaster recovery for a disaster recovery enabled application . 2.1.2. Disaster recovery protection for cloned and restored RBD volumes Disaster recovery protection can be enabled for cloned and restored RADOS Block Device (RBD) volumes during DR policy creation for Regional-DR. For more information, see Disaster recovery protection for cloned and restored RBD volumes . 2.1.3. Setting up DR in clusters with overlapping pod and service CIDR The ODF CLI tool can be used on existing OpenShift deployments with overlapping pod and service CIDR to verify the clusters meet the prerequisites for peering. The tool verifies the two clusters have non-overlapping service and pod Classless Inter-Domain Routing (CIDR). For more information, see Requirements for enabling Regional-DR . 2.1.4. VM DR protection for cloned volume DR protection is simplified and automatically decouples parent and child so that each one can independently be DR protected. This eliminates the dependency on the parent volume and VM and its DR status. 2.2. VMware vSphere8 support OpenShift Data Foundation supports deployment on VMware vSphere version 8. 2.3. Storage class with 2-way replication for CephFS Storage class with 2-way replication (replica-2) enables reduction in overhead with CephFS when data resiliency is not a primary concern. The 2-way replication reduces the amount of storage space used and decreases the level of fault tolerance. For more information, see Using 2-way replication with CephFS . 2.4. Key Rotation for PV encryption Enabling key rotation when using the key management system (KMS) helps to achieve the security common practices that require periodic encryption key rotation. For more information, see Enabling key rotation when using KMS . 2.5. Azure Key Vault support on OpenShift Data Foundation KMS OpenShift Data Foundation on Microsoft Azure platform supports Azure Key Vault for cluster-wide PV encryption. This Key Vault helps to use a local native solution for Azure instead of a third party tool. For more information, see Creating an OpenShift Data Foundation cluster . 2.6. Manual setting of Multicloud Object Gateway credentials to an account Multicloud Object Gateway credentials can be set manually using the NooBaa CLI commands. For more information, see Setting Multicloud Object Gateway account credentials using CLI command . 2.7. Downloading the OpenShift Data Foundation CLI tool from the user interface With the OpenShift Data Foundation command line interface (CLI) tool, a Data Foundation environment can be effectively managed and troubleshot from a terminal. A compatible version of the CLI tool can be downloaded from the customer portal .

Commands:
Chapter 9. Configuring Kafka Streams for Apache Kafka enables the deployment of Kafka components on OpenShift through highly configurable custom resources. These resources leverage Custom Resource Definitions (CRDs) to extend OpenShift capabilities, offering a flexible way to manage Kafka components. After a new custom resource type is added to your cluster by installing a CRD, you can create instances of the resource based on its specification. Many additional configuration options can be specified in a custom resource, some common and some specific to a particular component. Use custom resources to configure the following components: Kafka clusters Node pools for Kafka clusters MirrorMaker source and target clusters Kafka Connect Kafka Bridge Streams for Apache Kafka provides example configuration files , which can serve as a starting point when building your own Kafka component configuration for deployment. For detailed configuration instructions and examples, see the guide for Deploying and Managing Streams for Apache Kafka .

Commands: