mtpti5iD/redhat-docs_dataset huggingface dataset:
Preface Debezium is a set of distributed services that capture row-level changes in your databases so that your applications can see and respond to those changes. Debezium records all row-level changes committed to each database table. Each application reads the transaction logs of interest to view all operations in the order in which they occurred. This guide provides details about using the following Debezium topics: Chapter 1, High level overview of Debezium Chapter 2, Required custom resource upgrades Chapter 3, Debezium connector for Db2 Chapter 4, Debezium connector for JDBC (Developer Preview) Developer Preview Chapter 5, Debezium connector for MongoDB Chapter 6, Debezium connector for MySQL Chapter 7, Debezium Connector for Oracle Chapter 8, Debezium connector for PostgreSQL Chapter 9, Debezium connector for SQL Server Chapter 10, Monitoring Debezium Chapter 11, Debezium logging Chapter 12, Configuring Debezium connectors for your application Chapter 13, Applying transformations to modify messages exchanged with Apache Kafka Chapter 14, Developing Debezium custom data type converters Making open source more inclusive Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright's message . Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. To propose improvements, open a Jira issue and describe your suggested changes. Provide as much detail as possible to enable us to address your request quickly. Prerequisite You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one. Procedure Click the following link: Create issue . In the Summary text box, enter a brief description of the issue. In the Description text box, provide the following information: The URL of the page where you found the issue. A detailed description of the issue. You can leave the information in any other fields at their default values. Click Create to submit the Jira issue to the documentation team. Thank you for taking the time to provide feedback.

Commands:
Chapter 1. Red Hat JBoss Web Server 6.0 Service Pack 5 Welcome to the Red Hat JBoss Web Server version 6.0 Service Pack 5 release. Red Hat JBoss Web Server is a fully integrated and certified set of components for hosting Java web applications. It consists of an application server (Apache Tomcat servlet container) and the Apache Tomcat Native Library. JBoss Web Server includes the following key components: Apache Tomcat is a servlet container in accordance with the Java Servlet Specification. JBoss Web Server contains Apache Tomcat 10.1. The Apache Tomcat Native Library improves Tomcat scalability, performance, and integration with native server technologies. Tomcat-vault is an extension for the JBoss Web Server that is used for securely storing passwords and other sensitive information used by a JBoss Web Server. The mod_cluster library enables communication between JBoss Web Server and the Apache HTTP Server mod_proxy_cluster module. The mod_cluster library enables you to use the Apache HTTP Server as a load balancer for JBoss Web Server. For more information about configuring mod_cluster , or for information about installing and configuring alternative load balancers such as mod_jk and mod_proxy , see the Apache HTTP Server Connectors and Load Balancing Guide . Apache portable runtime (APR) is a runtime that provides an OpenSSL-based TLS implementation for the HTTP connectors. JBoss Web Server provides a distribution of APR for supported Windows platforms only. For Red Hat Enterprise Linux, you can use the APR package that the operating system provides. OpenSSL is a software library that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols and includes a basic cryptographic library. JBoss Web Server provides a distribution of OpenSSL for supported Windows platforms only. For Red Hat Enterprise Linux, you can use the OpenSSL package that the operating system provides. This release of JBoss Web Server includes a moderate security update. This release of JBoss Web Server provides OpenShift images based on Red Hat Enterprise Linux 8. Note Red Hat distributes the JBoss Web Server 6.0 Service Pack 5 release in RPM packages only. This service pack release is not available in archive file format.

Commands:
7.18. brltty 7.18.1. RHBA-2012:1231 - brltty bug fix update Updated brltty packages that fix two bugs are now available for Red Hat Enterprise Linux 6. BRLTTY is a background process (daemon) which provides access to the Linux console (when in text mode) for a blind person using a refreshable braille display. It drives the braille display, and provides complete screen review functionality. Bug Fixes BZ# 684526 Previously, building the brltty package could fail on the ocaml's unpackaged files error. This happened only if the ocaml package was pre-installed in the build root. The "--disable-caml-bindings" option has been added in the %configure macro so that the package now builds correctly. BZ#809326 Previously, the /usr/lib/libbrlapi.so symbolic link installed by the brlapi-devel package incorrectly pointed to ../../lib/libbrlapi.so. The link has been fixed to correctly point to ../../lib/libbrlapi.so.0.5. All users of brltty are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 6. Troubleshooting the Bare Metal Provisioning service Use the following procedures to diagnose issues in a red Hat OpenStack on OpenShift (RHOSO) environment that includes the Bare Metal Provisioning service (ironic). 6.1. Querying node event history records You can query the node event history records to identify issues with bare-metal nodes when an operation fails. Procedure Open a remote shell connection to the OpenStackClient pod: View the event history for a particular node: This command returns a list of the error events and node state transitions that occurred on the node. Each event is identified with an event UUID. View the details of a particular event that occurred on the node: Exit the openstackclient pod:

Commands:
oc rsh -n openstack openstackclient
openstack baremetal node history list <node_id>
openstack baremetal node history get <node_id> <event_uuid>
exit
32.9.2. Making the Kickstart File Available on the Network Network installations using kickstart are quite common, because system administrators can quickly and easily automate the installation on many networked computers. In general, the approach most commonly used is for the administrator to have both a BOOTP/DHCP server and an NFS server on the local network. The BOOTP/DHCP server is used to give the client system its networking information, while the actual files used during the installation are served by the NFS server. Often, these two servers run on the same physical machine, but they are not required to. Include the ks kernel boot option in the append line of a target in your pxelinux.cfg/default file to specify the location of a kickstart file on your network. The syntax of the ks option in a pxelinux.cfg/default file is identical to its syntax when used at the boot prompt. Refer to Section 32.11, "Starting a Kickstart Installation" for a description of the syntax and refer to Example 32.1, "Using the ks option in the pxelinux.cfg/default file" for an example of an append line. If the dhcpd.conf file on the DHCP server is configured to point to /var/lib/tftpboot/pxelinux.0 on the BOOTP server (whether on the same physical machine or not), systems configured to boot over the network can load the kickstart file and commence installation. Example 32.1. Using the ks option in the pxelinux.cfg/default file For example, if foo.ks is a kickstart file available on an NFS share at 192.168.0.200:/export/kickstart/ , part of your pxelinux.cfg/default file might include:

Commands:
label 1 kernel RHEL6/vmlinuz append initrd=RHEL6/initrd.img ramdisk_size=10000 ks=nfs:192.168.0.200:/export/kickstart/foo.ks
Chapter 4. Knative Eventing Knative Eventing on OpenShift Container Platform enables developers to use an event-driven architecture with serverless applications. An event-driven architecture is based on the concept of decoupled relationships between event producers and event consumers. Event producers create events, and event sinks , or consumers, receive events. Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and sinks. These events conform to the CloudEvents specifications , which enables creating, parsing, sending, and receiving events in any programming language. Knative Eventing supports the following use cases: Publish an event without creating a consumer You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events. Consume an event without creating a publisher You can use a trigger to consume events from a broker based on event attributes. The application receives events as an HTTP POST. To enable delivery to multiple types of sinks, Knative Eventing defines the following generic interfaces that can be implemented by multiple Kubernetes resources: Addressable resources Able to receive and acknowledge an event delivered over HTTP to an address defined in the status.address.url field of the event. The Kubernetes Service resource also satisfies the addressable interface. Callable resources Able to receive an event delivered over HTTP and transform it, returning 0 or 1 new events in the HTTP response payload. These returned events may be further processed in the same way that events from an external event source are processed. 4.1. Using the Knative broker for Apache Kafka The Knative broker implementation for Apache Kafka provides integration options for you to use supported versions of the Apache Kafka message streaming platform with OpenShift Serverless. Kafka provides options for event source, channel, broker, and event sink capabilities. Knative broker for Apache Kafka provides additional options, such as: Kafka source Kafka channel Kafka broker Kafka sink 4.2. Additional resources Installing the KnativeKafka custom resource Red Hat AMQ Streams documentation Red Hat AMQ Streams TLS and SASL on Apache Kafka documentation Event delivery

Commands:
3.2. C++ HotRod Client on RHEL 5 The C++ HotRod Client on Red Hat Enterprise Linux (RHEL) 5 has been deprecated in JBoss Data Grid 6.6.0, and is expected to be removed in version 7.0.0; the C++ HotRod Client for RHEL 6 and RHEL 7 will continue to be supported in JDG 7.0.0. Report a bug

Commands:
About This Reference Red Hat Directory Server (Directory Server) is a powerful and scalable distributed directory server based on the industry-standard Lightweight Directory Access Protocol (LDAP). Directory Server is the cornerstone for building a centralized and distributed data repository that can be used in an intranet, over an extranet with trading partners, or over the public Internet to reach customers. This reference covers the server configuration and the command-line utilities. It is designed primarily for directory administrators and experienced directory users who want to use the command-line to access the directory. After configuring the server, use this reference to help maintain it. The Directory Server can also be managed through the Directory Server Console, a graphical user interface. The Red Hat Directory Server Administration Guide describes how to do this and explains individual administration tasks more fully. 1. Directory Server Overview The major components of Directory Server include: An LDAP server - The LDAP v3-compliant network daemon. Directory Server Console - A graphical management console that dramatically reduces the effort of setting up and maintaining your directory service. SNMP agent - Can monitor the Directory Server using the Simple Network Management Protocol (SNMP).

Commands:
Chapter 2. The 64k page size kernel kernel-64k is an additional, optional 64-bit ARM architecture kernel package that supports 64k pages. This additional kernel exists alongside the RHEL 9 for ARM kernel which supports 4k pages. Optimal system performance directly relates to different memory configuration requirements. These requirements are addressed by the two variants of kernel, each suitable for different workloads. RHEL 9 on 64-bit ARM hardware thus offers two MMU page sizes: 4k pages kernel for efficient memory usage in smaller environments, kernel-64k for workloads with large, contiguous memory working sets. The 4k pages kernel and kernel-64k do not differ in the user experience as the user space is the same. You can choose the variant that addresses your situation the best. 4k pages kernel Use 4k pages for more efficient memory usage in smaller environments, such as those in Edge and lower-cost, small cloud instances. In these environments, increasing the physical system memory amounts is not practical due to space, power, and cost constraints. Also, not all 64-bit ARM architecture processors support a 64k page size. The 4k pages kernel supports graphical installation using Anaconda, system or cloud image-based installations, as well as advanced installations using Kickstart. kernel-64k The 64k page size kernel is a useful option for large datasets on ARM platforms. kernel-64k is suitable for memory-intensive workloads as it has significant gains in overall system performance, namely in large database, HPC, and high network performance. You must choose page size on 64-bit ARM architecture systems at the time of installation. You can install kernel-64k only by Kickstart by adding the kernel-64k package to the package list in the Kickstart file. Additional resources Installing Kernel-64k on ARM

Commands:
Chapter 33. InlineLogging schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , ZookeeperClusterSpec The type property is a discriminator that distinguishes use of the InlineLogging type from ExternalLogging . It must have the value inline for the type InlineLogging . Property Description type Must be inline . string loggers A Map from logger name to logger level. map

Commands:
Chapter 4. Advisories related to this release The following advisories are issued to document bug fixes and CVE fixes included in this release: RHSA-2023:5745 RHSA-2023:5746 RHSA-2023:5747 RHSA-2023:5750 RHSA-2023:5751 RHSA-2023:5752 RHSA-2023:5753 Revised on 2024-05-03 15:37:07 UTC

Commands:
16.5. Disabling and Re-enabling Service Entries Active services can be accessed by other services, hosts, and users within the domain. There can be situations when it is necessary to remove a host or a service from activity. However, deleting a service or a host removes the entry and all the associated configuration, and it removes it permanently. 16.5.1. Disabling Service Entries Disabling a service prevents domain users from access it without permanently removing it from the domain. This can be done by using the service-disable command. For a service, specify the principal for the service. For example: Important Disabling a host entry not only disables that host. It disables every configured service on that host as well. 16.5.2. Re-enabling Services Disabling a service essentially kills its current, active keytabs. Removing the keytabs effectively removes the service from the IdM domain without otherwise touching its configuration entry. To re-enable a service, simply use the ipa-getkeytab command. The -s option sets which IdM server to request the keytab, -p gives the principal name, and -k gives the file to which to save the keytab. For example, requesting a new HTTP keytab:

Commands:
[jsmith@ipaserver ~]USD kinit admin [jsmith@ipaserver ~]USD ipa service-disable HTTP/server.example.com
ipa-getkeytab -s ipaserver.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
13.7. Locking Repartitioning polkit enables you to set permissions for individual operations. For udisks2 , the utility for disk management services, the configuration is located at /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy . This file contains a set of actions and default values, which can be overridden by system administrator. Important Remember that polkit configuration stored in /etc overrides the configuration shipped by packages in /usr/share/ . Procedure 13.7. To Prevent Users from Changing Disks Settings Create a file with the same content as in /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy . Do not change the /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy file, your changes will be overwritten by the package update. Delete the action you do not need and add the following lines to the /etc/polkit-1/actions/org.freedesktop.udisks2.policy file: Replace no by auth_admin if you want to ensure only the root user is able to carry out the action. Save the changes. When the user tries to change the disks settings, the following message is returned:

Commands:
cp /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy /etc/share/polkit-1/actions/org.freedesktop.udisks2.policy
<action id="org.freedesktop.udisks2.modify-device"> <message>Authentication is required to modify the disks settings</message> <defaults> <allow_any>no</allow_any> <allow_inactive>no</allow_inactive> <allow_active>yes</allow_active> </defaults> </action>
Authentication is required to modify the disks settings
Preface Red Hat Enterprise Linux minor releases are an aggregation of individual enhancement, security, and bug fix errata. The Red Hat Enterprise Linux 6.9 Release Notes document describes the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release, as well as known problems. The Technical Notes document provides a list of notable bug fixes, all currently available Technology Previews, deprecated functionality, and other information. Capabilities and limits of Red Hat Enterprise Linux 6 as compared to other versions of the system are available in the Red Hat Knowledgebase article available at https://access.redhat.com/articles/rhel-limits . For information regarding the Red Hat Enterprise Linux life cycle, refer to https://access.redhat.com/support/policy/updates/errata/ .

Commands:
probe::tcpmib.CurrEstab Name probe::tcpmib.CurrEstab - Update the count of open sockets Synopsis tcpmib.CurrEstab Values sk pointer to the struct sock being acted on op value to be added to the counter (default value of 1) Description The packet pointed to by skb is filtered by the function tcpmib_filter_key . If the packet passes the filter is is counted in the global CurrEstab (equivalent to SNMP's MIB TCP_MIB_CURRESTAB)

Commands:
Chapter 12. Network Time Protocol You need to ensure that systems within your Red Hat OpenStack Platform cluster have accurate and consistent timestamps between systems. Red Hat OpenStack Platform on Red Hat Enterprise Linux 8 supports Chrony for time management. For more information, see Using the Chrony suite to configure NTP . 12.1. Why consistent time is important Consistent time throughout your organization is important for both operational and security needs: Identifying a security event Consistent timekeeping helps you correlate timestamps for events on affected systems so that you can understand the sequence of events. Authentication and security systems Security systems can be sensitive to time skew, for example: A kerberos-based authentication system might refuse to authenticate clients that are affected by seconds of clock skew. Transport layer security (TLS) certificates depend on a valid source of time. A client to server TLS connection fails if the difference between client and server system times exceeds the Valid From date range. Red Hat OpenStack Platform services Some core OpenStack services are especially dependent on accurate timekeeping, including High Availability (HA) and Ceph. 12.2. NTP design Network time protocol (NTP) is organized in a hierarchical design. Each layer is called a stratum. At the top of the hierarchy are stratum 0 devices such as atomic clocks. In the NTP hierarchy, stratum 0 devices provide reference for publicly available stratum 1 and stratum 2 NTP time servers. Do not connect your data center clients directly to publicly available NTP stratum 1 or 2 servers. The number of direct connections would put unnecessary strain on the public NTP resources. Instead, allocate a dedicated time server in your data center, and connect the clients to that dedicated server. Configure instances to receive time from your dedicated time servers, not the host on which they reside. Note Service containers running within the Red Hat OpenStack Platform environment still receive time from the host on which they reside.

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ OpenWire JMS examples require a running message broker with a queue named exampleQueue . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named exampleQueue . USD <broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2020-10-08 11:29:04 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop