mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 19. Configuring the IO Subsystem 19.1. IO Subsystem Overview The io subsystem defines the XNIO workers and buffer pools used by other subsystems, such as Undertow and Remoting. These workers and buffer pools are defined within the following components in the io subsystem: Default IO Subsystem Configuration <subsystem xmlns="urn:jboss:domain:io:3.0"> <worker name="default"/> <buffer-pool name="default"/> </subsystem> 19.2. Configuring a Worker Workers are XNIO worker instances. An XNIO worker instance is an abstraction layer for the Java NIO APIs, which provide functionality such as management of IO and worker threads as well as SSL support. By default, JBoss EAP provides single worker called default , but more can be defined. Updating an Existing Worker To update an existing worker: Creating a New Worker To create a new worker: Deleting a Worker To delete a worker: For a full list of the attributes available for configuring workers, please see the IO Subsystem Attributes section. 19.3. Configuring a Buffer Pool Note IO buffer pools are deprecated, but they are still set as the default in the current release. Buffer pools are pooled NIO buffer instances. Changing the buffer size has a big impact on application performance. For most servers, the ideal buffer size is usually 16k. For more information about configuring Undertow byte buffer pools, see the Configuring Byte Buffer Pools section of the Configuration Guide for JBoss EAP. Updating an Existing Buffer Pool To update an existing buffer pool: Creating a Buffer Pool To create a new buffer pool: Deleting a Buffer Pool To delete a buffer pool: For a full list of the attributes available for configuring buffer pools, please see the IO Subsystem Attributes section. 19.4. Tuning the IO Subsystem For tips on monitoring and optimizing performance for the io subsystem, see the IO Subsystem Tuning section of the Performance Tuning Guide .

Commands:
<subsystem xmlns="urn:jboss:domain:io:3.0"> <worker name="default"/> <buffer-pool name="default"/> </subsystem>
/subsystem=io/worker=default:write-attribute(name=io-threads,value=10)
reload
/subsystem=io/worker=newWorker:add
/subsystem=io/worker=newWorker:remove
reload
/subsystem=io/buffer-pool=default:write-attribute(name=direct-buffers,value=true)
reload
/subsystem=io/buffer-pool=newBuffer:add
/subsystem=io/buffer-pool=newBuffer:remove
reload
36.2. Preparing to Upgrade Before upgrading the kernel, take a few precautionary steps. The first step is to make sure working boot media exists for the system in case a problem occurs. If the boot loader is not configured properly to boot the new kernel, the system cannot be booted into Red Hat Enterprise Linux without working boot media. For example, to create a boot diskette, login as root, and type the following command at a shell prompt: Note Refer to the mkbootdisk man page for more options. Creating bootable media via CD-Rs, CD-RWs, and USB flash drives are also supported given the system BIOS also supports it. Reboot the machine with the boot media and verify that it works before continuing. Hopefully, the media is not needed, but store it in a safe place just in case. To determine which kernel packages are installed, execute the following command at a shell prompt: The output contains some or all of the following packages, depending on the system's architecture (the version numbers and packages may differ): From the output, determine which packages need to be download for the kernel upgrade. For a single processor system, the only required package is the kernel package. Refer to Section 36.1, "Overview of Kernel Packages" for descriptions of the different packages. In the file name, each kernel package contains the architecture for which the package was built. The format is kernel- <variant> - <version> . <arch> .rpm, where <variant> is smp , utils , or so forth. The <arch> is one of the following: x86_64 for the AMD64 architecture ia64 for the Intel (R) Itanium TM architecture ppc64 for the IBM (R) eServer TM pSeries TM architecture ppc64 for the IBM (R) eServer TM iSeries TM architecture s390 for the IBM (R) S/390 (R) architecture s390x for the IBM (R) eServer TM zSeries (R) architecture x86 variant: The x86 kernels are optimized for different x86 versions. The options are as follows: i686 for Intel (R) Pentium (R) II, Intel (R) Pentium (R) III, Intel (R) Pentium (R) 4, AMD Athlon (R), and AMD Duron (R) systems

Commands:
/sbin/mkbootdisk `uname -r`
-qa | grep kernel
kernel-2.6.9-5.EL kernel-devel-2.6.9-5.EL kernel-utils-2.6.9-5.EL kernel-doc-2.6.9-5.EL kernel-smp-2.6.9-5.EL kernel-smp-devel-2.6.9-5.EL kernel-hugemem-devel-2.6.9-5.EL
15.12. Managing Deleted Entries with Replication When an entry is deleted, it is not immediately removed from the database. Rather, it is converted into a tombstone entry, a kind of backup entry that is used by servers in replication to resolve specific conflicts (orphaned entries). The tombstone entry is the original entry with a modified DN, an added nsTombstone object class, but the attributes are removed from the index. Tombstones are not preserved indefinitely. A purge job is run periodically, at a specified interval (set in the nsDS5ReplicaTombstonePurgeInterval attribute); the purge removes old tombstone entries. Tombstone entries are saved for a given amount of time (set in the nsDS5ReplicaPurgeDelay attribute); once a tombstone entry is older than the delay period, it is reaped at the purge job. Both the purge delay and the purge interval are set on the replica entry in the cn=replica,cn= replicated suffix ,cn=mapping tree,cn=config configuration entry. There are two considerations when defining the purge settings for replication: The purge operation is time-consuming, especially if the server handles a lot of delete operations. Do not set the purge interval too low or it could consume too many server resources and affect performance. Suppliers use change information, including tombstone entries, to prime replication after initialization. There should be enough of a backlog of changes to effectively re-initialize consumers and to resolve replication conflicts. Do not set the purge delay (the age of tombstone entries) too low or you could lose information required to resolve replication conflicts. Set the purge delay so that it is slightly longer than the longest replication schedule in the replication topology. For example, if the longest replication interval is 24 hours, keep tombstone entries around for 25 hours. This ensures that there is enough change history to initialize consumers and prevent the data stored in different suppliers from diverging. When you use the dsconf replication set command, the --repl-tombstone-purge-interval= seconds option sets the nsDS5ReplicaTombstonePurgeInterval attribute and the --repl-purge-delay= seconds option the nsDS5ReplicaPurgeDelay attribute. For example, to set the tombstone purge interval to 43200 (12 hours) and the replica purge delay to 90000 (25 hours): Note To clean up the tombstone entries and the state information immediately, set a very small value to the nsDS5ReplicaTombstonePurgeInterval and nsDS5ReplicaPurgeDelay attributes. Both attributes have values set in seconds, so the purge operations can be initiated almost immediately. Warning Always use the purge intervals to clean out tombstone entries from the database. Never delete tombstone entries manually.

Commands:
dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication set --repl-tombstone-purge-interval=43200 --repl-purge-delay=90000
Chapter 3. Registering and connecting systems to Red Hat Insights to execute tasks To work with Red Hat Insights, you need to register systems to Insights, and enable system communication with Insights. In addition to communicating with Insights, you need to enable and install dependencies on Satellite 6.11+, Remote Host Configuration (rhc), rhc-worker-playbook and ansible , so that you can use task services, and other services in the Automation Toolkit. Additional resources Red Hat Insights data and application security

Commands:
probe::udp.recvmsg.return Name probe::udp.recvmsg.return - Fires whenever an attempt to receive a UDP message received is completed Synopsis udp.recvmsg.return Values name The name of this probe family IP address family dport UDP destination port saddr A string representing the source IP address sport UDP source port size Number of bytes received by the process daddr A string representing the destination IP address Context The process which received a UDP message

Commands:
8.221. tomcat6 8.221.1. RHBA-2013:1721 - tomcat6 bug fix update Updated tomcat6 packages that fix several bugs are now available for Red Hat Enterprise Linux 6. Apache Tomcat is a servlet container for the Java Servlet and JavaServer Pages (JSP) technologies. Bug Fixes BZ# 845786 Previously, an attempt to build the tomcat6-docs-webapp package failed when Red Hat Enterprise Linux was running on IBM System z or 64-bit IBM POWER Series computers. With this update, no architecture is set in the build target and the package can be built as expected. BZ# 915447 When a user, whose name did not correspond to any existing group name, was specified in the /etc/sysconfig/tomcat6 file, the Tomcat web server failed to start. This update applies a patch to fix this bug and Tomcat no longer fails in the described scenario. BZ# 950647 Due to a bug in the checkpidfile() function, an attempt to execute the "service tomcat6 status" command failed and an error message was returned. The underlying source code has been modified to fix this bug and the command now works properly. BZ# 960255 Due to a bug in the checkpidfile() function, the status script did not return the correct PID. This bug has been fixed and the status script now returns the correct PID as expected. BZ# 977685 The Tomcat web server included a version of the tomcat-juli.jar file that was hard coded to use classes from the java.util.logging package instead of the log4j framework. Consequently, Tomcat could not be configured to use log4j unless the complete version of the tomcat-juli.jar and tomcat-juli-adapters.jar files had been downloaded. With this update, the tomcat6 packages now contain the correct versions of these files to configure log4j. BZ# 989527 When multiple tomcat instances were configured as described in the /etc/sysconfig/tomcat6 configuration file and the instance name was different from the name of the tomcat directory, the "service status" command failed. With this update, the underlying source code has been modified to fix this bug and the command no longer fails in the described scenario. Users of tomcat6 are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 2. Running Java applications with Shenandoah garbage collector You can run your Java application with the Shenandoah garbage collector (GC). Prerequisites Installed Red Hat build of OpenJDK. See Installing Red Hat build of OpenJDK 17 on Red Hat Enterprise Linux in the Installing and using Red Hat build of OpenJDK 17 on RHEL guide. Procedure Run your Java application with Shenandoah GC by using -XX:+UseShenandoahGC JVM option. USD java <PATH_TO_YOUR_APPLICATION> -XX:+UseShenandoahGC

Commands:
java <PATH_TO_YOUR_APPLICATION> -XX:+UseShenandoahGC
Part IX. Decision engine in Red Hat Decision Manager As a business rules developer, your understanding of the decision engine in Red Hat Decision Manager can help you design more effective business assets and a more scalable decision management architecture. The decision engine is the Red Hat Decision Manager component that stores, processes, and evaluates data to execute business rules and to reach the decisions that you define. This document describes basic concepts and functions of the decision engine to consider as you create your business rule system and decision services in Red Hat Decision Manager.

Commands:
Appendix B. Generating Keycloak host names automatically OpenShift routes has support for automatically generating host names by using a set pattern. This feature can integrate with Red Hat's build of Keycloak (RHBK) operator running on OpenShift. Prerequisites Red Hat OpenShift Container Platform version 4.13 or later. Installation of the RHBK operator. Access to the OpenShift web console with the cluster-admin role. A workstation with the oc binary installed. Procedure Enable the automatically generated route hostname feature. Under the .spec section, remove the entire hostname section, and replace it with the ingress section and className property within the Keycloak resource: Example spec: ... hostname: hostname: example.com ... Example spec: ... ingress: className: openshift-default ... Note To view all of the available Ingress classes, run the following command: Click the Save button. Verify the automatically generated hostname by clicking the Reload button to view the latest configuration: Example spec: ... hostname: hostname: example-keycloak-ingress-keycloak-system.apps.rhtas.example.com ...

Commands:
spec: hostname: hostname: example.com
spec: ingress: className: openshift-default
oc get ingressclass
spec: hostname: hostname: example-keycloak-ingress-keycloak-system.apps.rhtas.example.com
Chapter 7. Notable changes to containers A set of container images is available for Red Hat Enterprise Linux (RHEL) 8.1. Notable changes include: Rootless containers are fully supported in RHEL 8.1. Rootless containers are containers that are created and managed by regular system users without administrative permissions. This allows users to maintain their identity, including such things as credentials to container registries. You can try rootless containers using the podman and buildah commands. For more information: for rootless containers, see Setting up rootless containers . for buildah , see Building container images with Buildah . for podman , see Building, running, and managing containers . The toolbox RPM package is fully supported in RHEL 8.1. The toolbox command is a utility often used with container-oriented operating systems, such as Red Hat CoreOS. With toolbox , you can troubleshoot and debug host operating systems by launching a container that includes a large set of troubleshooting tools for you to use, without having to install those tools on the host system. Running the toolbox command starts a rhel-tools container that provides root access to the host, for fixing or otherwise working with that host. See the new documentation on Running containers with runlabels . The podman package has been upgraded to upstream version 1.4.2. For information on features added to podman since version 1.0.0, which was used in RHEL 8.0, refer to descriptions of the latest podman releases on Github .

Commands:
Chapter 13. Real-Time Kernel About Red Hat Enterprise Linux for Real Time Kernel The Red Hat Enterprise Linux for Real Time Kernel is designed to enable fine-tuning for systems with extremely high determinism requirements. The major increase in the consistency of results can, and should, be achieved by tuning the standard kernel. The real-time kernel enables gaining a small increase on top of increase achieved by tuning the standard kernel. The real-time kernel is available in the rhel-7-server-rt-rpms repository. The Installation Guide contains the installation instructions and the rest of the documentation is available at Product Documentation for Red Hat Enterprise Linux for Real Time . kernel-rt sources updated The kernel-rt sources have been upgraded to be based on the latest Red Hat Enterprise Linux kernel source tree, which provides a number of bug fixes and enhancements over the version. (BZ# 1553351 ) The SCHED_DEADLINE scheduler class for real time kernel fully supported The SCHED_DEADLINE scheduler class for the real-time kernel, which was introduced in Red Hat Enterprise Linux 7.4 as a Technology Preview, is now fully supported. The scheduler enables predictable task scheduling based on application deadlines. SCHED_DEADLINE benefits periodic workloads by guaranteeing timing isolation, which is based not only on a fixed priority but also on the applications' timing requirements. (BZ#1297061) rt-entsk prevents IPI generation and delay of realtime tasks The chrony daemon, chronyd , enables or disables network timestamping, which activates a static key within the kernel. When a static key is enabled or disabled, three inter-processor interrupt (IPIs) are generated to notify other processors of the activation. Previously, rapid activation and deactivation of the chronyd static keys led to a delay of a realtime task. Consequently, a latency spike occurred. With this update, systemd starts the rt-entsk program, which keeps timestamping enabled and prevents the IPIs from being generated. As a result, IPI generation no longer occurs in a rapid succession, and realtime tasks are no longer delayed due to this bug. (BZ# 1616038 )

Commands:
Chapter 8. Kubernetes This guide describes different ways to configure and deploy a Camel Quarkus application on kubernetes. It also describes some specific use cases for Knative and Service Binding. 8.1. Kubernetes Quarkus supports generating resources for vanilla Kubernetes, OpenShift and Knative. Furthermore, Quarkus can deploy the application to a target Kubernetes cluster by applying the generated manifests to the target cluster's API Server. For more information, see the Quarkus Kubernetes guide . 8.2. Knative The Camel Quarkus extensions whose consumers support Knative deployment are: camel-quarkus-grpc camel-quarkus-knative camel-quarkus-platform-http camel-quarkus-rest camel-quarkus-servlet camel-quarkus-telegram with webhook camel-quarkus-vertx-websocket 8.3. Service binding Quarkus also supports the Service Binding Specification for Kubernetes to bind services to applications. The following Camel Quarkus extensions can be used with Service Binding: camel-quarkus-kafka

Commands:
9. Devices and Device Drivers PCI Device Ordering In Red Hat Enterprise Linux 6, the PCI device ordering is based on the PCI device enumeration. PCI device enumeration is based on the PCI enumeration algorithm (depth first then breadth) and is constant per system type. Additionally, once the devices are discovered, the module loading process is sequentialized, providing persistent naming of the interfaces. 9.1. Technology Previews Brocade BFA Driver The Brocade BFA driver is considered a Technology Preview feature in Red Hat Enterprise Linux 6. The BFA driver supports Brocade FibreChannel and FCoE mass storage adapters. SR-IOV on the be2net driver The SR-IOV functionality of the Emulex be2net driver is considered a Technology Preview in Red Hat Enterprise Linux 6.

Commands:
Chapter 2. New features and enhancements This section lists new features and feature enhancements available in Red Hat Trusted Application Pipeline 1.4. You can now install RHTAP using a single container image Starting from RHTAP 1.4, we recommend that you install RHTAP via the rhtap-cli container image available through Red Hat Ecosystem Catalog . Compared to the binary-based installation, using the RHTAP container image simplifies the installation process and is fully supported on all operating systems.

Commands:
Chapter 19. Users and Roles 19.1. Introduction to Users In Red Hat Virtualization, there are two types of user domains: local domain and external domain. A default local domain called the internal domain and a default user admin is created during the the Manager installation process. You can create additional users on the internal domain using ovirt-aaa-jdbc-tool . User accounts created on local domains are known as local users. You can also attach external directory servers such as Red Hat Directory Server, Active Directory, OpenLDAP, and many other supported options to your Red Hat Virtualization environment and use them as external domains. User accounts created on external domains are known as directory users. Both local users and directory users need to be assigned with appropriate roles and permissions through the Administration Portal before they can function in the environment. There are two main types of user roles: end user and administrator. An end user role uses and manages virtual resources from the VM Portal. An administrator role maintains the system infrastructure using the Administration Portal. The roles can be assigned to the users for individual resources like virtual machines and hosts, or on a hierarchy of objects like clusters and data centers.

Commands:
Chapter 2. Enhancements The enhancements added in this release are outlined below. 2.1. Kafka 2.7.0 enhancements For an overview of the enhancements introduced with Kafka 2.7.0, refer to the Kafka 2.7.0 Release Notes . 2.2. OAuth 2.0 authentication and authorization This release includes the following enhancements to OAuth 2.0 token-based authentication and authorization. Checks on JWT access tokens You can now configure two additional checks on JWT access tokens. Both of these checks are configured in the OAuth 2.0 authentication listener configuration. Custom claim checks Custom claim checks impose custom rules on the validation of JWT access tokens by Kafka brokers. They are defined using JsonPath filter queries. If an access token does not contain the necessary data, it is rejected. When using introspection endpoint token validation, the custom check is applied to the introspection endpoint response JSON. To configure custom claim checks, add the oauth.custom.claim.check option to the server.properties file and define a JsonPath filter query. Custom claim checks are disabled by default. See Configuring OAuth 2.0 support for Kafka brokers Audience checks Your authorization server might provide aud (audience) claims in JWT access tokens. When audience checks are enabled, the Kafka broker rejects tokens that do not contain the broker's clientId in their aud claims. To enable audience checks, set the oauth.check.audience option to true . Audience checks are disabled by default. See Configuring OAuth 2.0 support for Kafka brokers Support for OAuth 2.0 over SASL PLAIN authentication You can now configure the PLAIN mechanism for OAuth 2.0 authentication between Kafka clients and Kafka brokers. Previously, the only supported authentication mechanism was OAUTHBEARER. PLAIN is a simple authentication mechanism supported by all Kafka client tools (including developer tools such as kafkacat). AMQ Streams includes server-side callbacks that enable PLAIN to be used with OAuth 2.0 authentication. These capabilities are referred to as OAuth 2.0 over PLAIN . Note Red Hat recommends using OAUTHBEARER authentication for clients whenever possible. OAUTHBEARER provides a higher level of security than PLAIN because client credentials are never shared with Kafka brokers. Consider using PLAIN only with Kafka clients that do not support OAUTHBEARER. When used with the provided OAuth 2.0 over PLAIN callbacks, Kafka clients can authenticate with Kafka brokers using either of the following methods: Client ID and secret (by using the OAuth 2.0 client credentials mechanism) A long-lived access token, obtained manually at configuration time To use PLAIN, you must enable it in the server.properties file, in the OAuth authentication listener configuration. See OAuth 2.0 authentication mechanisms and Configuring OAuth 2.0 support for Kafka brokers

Commands: