mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Designing the Directory Topology Chapter 4, Designing the Directory Tree covers how the directory service stores entries. Because Red Hat Directory Server can store a large number of entries, it is possible to distribute directory entries across more than one server. The directory's topology describes how the directory tree is divided among multiple physical Directory Servers and how these servers link with one another. This chapter describes planning the topology of the directory service. 6.1. Topology Overview Directory Server can support a distributed directory , where the directory tree (designed in Chapter 4, Designing the Directory Tree ) is spread across multiple physical Directory Servers. The way the directory is divided across those servers helps accomplish the following: Achieve the best possible performance for directory-enabled applications. Increase the availability of the directory service. Improve the management of the directory service. The database is the basic unit for jobs such as replication, performing backups, and restoring data. A single directory can be divided into manageable pieces and assigned to separate databases. These databases can then be distributed between a number of servers, reducing the workload for each server. More than one database can be located on a single server. For example, one server might contain three different databases. When the directory tree is divided across several databases, each database contains a portion of the directory tree, called a suffix . For example, one database can be used to store only entries in the ou=people,dc=example,dc=com suffix, or branch, of the directory tree. When the directory is divided between several servers, each server is responsible for only a part of the directory tree. The distributed directory service works similarly to the Domain Name Service (DNS), which assigns each portion of the DNS namespace to a particular DNS server. Likewise, the directory namespace can be distributed across servers while maintaining a directory service that, from a client's point of view, appears to be a single directory tree. The Directory Server also provides knowledge references , mechanisms for linking directory data stored in different databases. Directory Server includes two types of knowledge references; referrals and chaining . The remainder of this chapter describes databases and knowledge references, explains the differences between the two types of knowledge references, and describes how to design indexes to improve the performance of the databases.

Commands:
5.146. libevent 5.146.1. RHBA-2012:0968 - libevent bug fix update Updated libevent packages that fix one bug are now available for Red Hat Enterprise Linux 6. The libevent API provides a mechanism to execute a callback function when a specific event occurs on a file descriptor or after a timeout has been reached. Bug Fix BZ# 658051 Prior to this update, several multilib files in the optional repositories could cause conflicts. As a consequence, these files could not use both a primary and a secondary architecture. This update modifies the underlying source code so that no more multilib file conflicts occur. All users of libevent or applications that require the libevent library are advised to upgrade to these updated packages, which fix this bug.

Commands:
2.4. Cluster Utilization The Cluster Utilization section shows the cluster utilization for the CPU and memory in a heatmap. Figure 2.5. Cluster Utilization 2.4.1. CPU The heatmap of the CPU utilization for a specific cluster that shows the average utilization of the CPU for the last 24 hours. Hovering over the heatmap displays the cluster name. Clicking on the heatmap navigates to Compute Hosts and displays the results of a search on a specific cluster sorted by CPU utilization. The formula used to calculate the usage of the CPU by the cluster is the average host CPU utilization in the cluster. This is calculated by using the average host CPU utilization for each host over the last 24 hours to find the total average usage of the CPU by the cluster. 2.4.2. Memory The heatmap of the memory utilization for a specific cluster that shows the average utilization of the memory for the last 24 hours. Hovering over the heatmap displays the cluster name. Clicking on the heatmap navigates to Compute Hosts and displays the results of a search on a specific cluster sorted by memory usage. The formula used to calculate the memory usage by the cluster is the total utilization of the memory in the cluster in GB. This is calculated by using the average host memory utilization for each host over the last 24 hours to find the total average usage of memory by the cluster.

Commands:
Chapter 4. Running GFS on a GNBD Server Node You can run GFS on a GNBD server node, with some restrictions. In addition, running GFS on a GNBD server node reduces performance. The following restrictions apply when running GFS on a GNBD server node. Important When running GFS on a GNBD server node you must follow the restrictions listed; otherwise, the GNBD server node will fail. A GNBD server node must have local access to all storage devices needed to mount a GFS file system. The GNBD server node must not import ( gnbd_import command) other GNBD devices to run the file system. The GNBD server must export all the GNBDs in uncached mode, and it must export the raw devices, not logical volume devices. GFS must be run on top of a logical volume device, not raw devices. Note You may need to increase the timeout period on the exported GNBDs to accommodate reduced performance. The need to increase the timeout period depends on the quality of the hardware.

Commands:
7.12. bfa-firmware 7.12.1. RHBA-2013:0315 - bfa-firmware bug fix and enhancement update Updated bfa-firmware packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The bfa-firmware package contains the Brocade Fibre Channel Host Bus Adapter (HBA) Firmware to run Brocade Fibre Channel and CNA adapters. This package also supports the Brocade BNA network adapter. Note The bfa-firmware packages have been upgraded to upstream version 3.0.3.1, which provides a number of bug fixes and enhancements over the version. (BZ#830015) All users of bfa-firmware are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 134. AutoRestartStatus schema reference Used in: KafkaConnectorStatus , KafkaMirrorMaker2Status Property Description count The number of times the connector or task is restarted. integer connectorName The name of the connector being restarted. string lastRestartTimestamp The last time the automatic restart was attempted. The required format is 'yyyy-MM-ddTHH:mm:ssZ' in the UTC time zone. string

Commands:
Chapter 6. Kourier and Istio ingresses OpenShift Serverless supports the following two ingress solutions: Kourier Istio using Red Hat OpenShift Service Mesh The default is Kourier. 6.1. Kourier and Istio ingress solutions 6.1.1. Kourier Kourier is the default ingress solution for OpenShift Serverless. It has the following properties: It is based on envoy proxy. It is simple and lightweight. It provides the basic routing functionality that Serverless needs to provide its set of features. It supports basic observability and metrics. It supports basic TLS termination of Knative Service routing. It provides only limited configuration and extension options. 6.1.2. Istio using OpenShift Service Mesh Using Istio as the ingress solution for OpenShift Serverless enables an additional feature set that is based on what Red Hat OpenShift Service Mesh offers: Native mTLS between all connections Serverless components are part of a service mesh Additional observability and metrics Authorization and authentication support Custom rules and configuration, as supported by Red Hat OpenShift Service Mesh However, the additional features come with a higher overhead and resource consumption. For details, see the Red Hat OpenShift Service Mesh documentation. See the "Integrating Service Mesh with OpenShift Serverless" section of Serverless documentation for Istio requirements and installation instructions. 6.1.3. Traffic configuration and routing Regardless of whether you use Kourier or Istio, the traffic for a Knative Service is configured in the knative-serving namespace by the net-kourier-controller or the net-istio-controller respectively. The controller reads the KnativeService and its child custom resources to configure the ingress solution. Both ingress solutions provide an ingress gateway pod that becomes part of the traffic path. Both ingress solutions are based on Envoy. By default, Serverless has two routes for each KnativeService object: A cluster-external route that is forwarded by the OpenShift router, for example myapp-namespace.example.com . A cluster-local route containing the cluster domain, for example myapp.namespace.svc.cluster.local . This domain can and should be used to call Knative services from Knative or other user workloads. The ingress gateway can forward requests either in the serve mode or the proxy mode: In the serve mode, requests go directly to the Queue-Proxy sidecar container of the Knative service. In the proxy mode, requests first go through the Activator component in the knative-serving namespace. The choice of mode depends on the configuration of Knative, the Knative service, and the current traffic. For example, if a Knative Service is scaled to zero, requests are sent to the Activator component, which acts as a buffer until a new Knative service pod is started.

Commands:
Chapter 3. Getting started This chapter guides you through the steps to set up your environment and run a simple messaging program. 3.1. Prerequisites To build the example, Maven must be configured to use the Red Hat repository or a local repository . You must install the examples . You must have a message broker listening for connections on localhost . It must have anonymous access enabled. For more information, see Starting the broker . You must have a queue named queue . For more information, see Creating a queue . 3.2. Running Hello World The Hello World example calls createConnection() for each character of the string "Hello World", transferring one at a time. Because AMQ JMS Pool is in use, each call reuses the same underlying JMS Connection object. Procedure Use Maven to build the examples by running the following command in the <source-dir> /pooled-jms-examples directory. USD mvn clean package dependency:copy-dependencies -DincludeScope=runtime -DskipTests The addition of dependency:copy-dependencies results in the dependencies being copied into the target/dependency directory. Use the java command to run the example. On Linux or UNIX: USD java -cp "target/classes:target/dependency/*" org.messaginghub.jms.example.HelloWorld On Windows: > java -cp "target\classes;target\dependency\*" org.messaginghub.jms.example.HelloWorld Running it on Linux results in the following output: USD java -cp "target/classes/:target/dependency/*" org.messaginghub.jms.example.HelloWorld 2018-05-17 11:04:23,393 [main ] - INFO JmsPoolConnectionFactory - Provided ConnectionFactory is JMS 2.0+ capable. 2018-05-17 11:04:23,715 [localhost:5672]] - INFO SaslMechanismFinder - Best match for SASL auth was: SASL-ANONYMOUS 2018-05-17 11:04:23,739 [localhost:5672]] - INFO JmsConnection - Connection ID:104dfd29-d18d-4bf5-aab9-a53660f58633:1 connected to remote Broker: amqp://localhost:5672 Hello World The source code for the example is in the <source-dir> /pooled-jms-examples/src/main/java directory. The JNDI and logging configuration is in the <source-dir> /pooled-jms-examples/src/main/resources directory.

Commands:
mvn clean package dependency:copy-dependencies -DincludeScope=runtime -DskipTests
java -cp "target/classes:target/dependency/*" org.messaginghub.jms.example.HelloWorld
> java -cp "target\classes;target\dependency\*" org.messaginghub.jms.example.HelloWorld
java -cp "target/classes/:target/dependency/*" org.messaginghub.jms.example.HelloWorld 2018-05-17 11:04:23,393 [main ] - INFO JmsPoolConnectionFactory - Provided ConnectionFactory is JMS 2.0+ capable. 2018-05-17 11:04:23,715 [localhost:5672]] - INFO SaslMechanismFinder - Best match for SASL auth was: SASL-ANONYMOUS 2018-05-17 11:04:23,739 [localhost:5672]] - INFO JmsConnection - Connection ID:104dfd29-d18d-4bf5-aab9-a53660f58633:1 connected to remote Broker: amqp://localhost:5672 Hello World
2.10.2. Whitelisting Parameters The cgsnapshot utility also allows parameter whitelisting. If a parameter is whitelisted, it appears in the output generated by cgsnapshot . If a parameter is neither blacklisted or whitelisted, a warning appears informing of this: By default, there is no whitelist configuration file. To specify which file to use as a whitelist, use the -w option. For example: Specifying the -t option tells cgsnapshot to generate a configuration with parameters from the whitelist only.

Commands:
~]USD cgsnapshot -f ~/test/cgconfig_test.conf WARNING: variable cpu.rt_period_us is neither blacklisted nor whitelisted WARNING: variable cpu.rt_runtime_us is neither blacklisted nor whitelisted
~]USD cgsnapshot -w ~/test/my_whitelist.conf
Appendix A. Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. Let us know how we can improve it. Use the Create Issue form in Red Hat Jira to provide your feedback. The Jira issue is created in the Red Hat Satellite Jira project, where you can track its progress. Prerequisites Ensure you have registered a Red Hat account . Procedure Click the following link: Create Issue . If Jira displays a login error, log in and proceed after you are redirected to the form. Complete the Summary and Description fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form. Click Create .

Commands:
Appendix A. Example Configuration: Load Balancing Ceph Object Gateway Servers with HAProxy and Keepalived This appendix provides an example showing the configuration of HAProxy and Keepalived with a Ceph cluster. The Ceph Object Gateway allows you to assign many instances of the object gateway to a single zone so that you can scale out as load increases. Since each object gateway instance has its own IP address, you can use HAProxy and keepalived to balance the load across Ceph Object Gateway servers. In this configuration, HAproxy performs the load balancing across Ceph Object Gateway servers while Keepalived is used to manage the Virtual IP addresses of the Ceph Object Gateway servers and to monitor HAProxy. Another use case for HAProxy and keepalived is to terminate HTTPS at the HAProxy server. Red Hat Ceph Storage (RHCS) 1.3.x uses Civetweb, and the implementation in RHCS 1.3.x does not support HTTPS. You can use an HAProxy server to terminate HTTPS at the HAProxy server and use HTTP between the HAProxy server and the Civetweb gateway instances. This example includes this configuration as part of the procedure. A.1. Prerequisites To set up HAProxy with the Ceph Object Gateway, you must have: A running Ceph cluster; At least two Ceph Object Gateway servers within the same zone configured to run on port 80; At least two servers for HAProxy and keepalived. Note This procedure assumes that you have at least two Ceph Object Gateway servers running, and that you get a valid response when running test scripts over port 80.

Commands:
13.3. Performing a Driver Update During Installation You can perform a driver update during installation in the following ways: let the installer automatically find a driver update disk. let the installer prompt you for a driver update. use a boot option to specify a driver update disk. 13.3.1. Let the Installer Find a Driver Update Disk Automatically Attach a block device with the filesystem label OEMDRV before starting the installation process. The installer will automatically examine the device and load any driver updates that it detects and will not prompt you during the process. Refer to Section 13.2.1.1, "Preparing to use an image file on local storage" to prepare a storage device for the installer to find.

Commands:
Administration Guide Red Hat Certificate System 10 Covers management tasks such as adding users; requesting, renewing, and revoking certificates; publishing CRLs; and managing smart cards. Florian Delehaye Red Hat Customer Content Services fdelehay@redhat.com Marc Muehlfeld Red Hat Customer Content Services Petr Bokoc Red Hat Customer Content Services Filip Hanzelka Red Hat Customer Content Services Tomas Capek Red Hat Customer Content Services Ella Deon Ballard Red Hat Customer Content Services

Commands:
1.3. Concurrent Versions System (CVS) Concurrent Versions System , commonly abbreviated as CVS , is a centralized version control system with a client-server architecture. It is a successor to the older Revision Control System (RCS), and allows multiple developers to cooperate on the same project while keeping track of every change made to the files that are under revision control. 1.3.1. Installing and Configuring CVS Installing the cvs Package In Red Hat Enterprise Linux 6, CVS is provided by the cvs package. To install the cvs package and all its dependencies on your system, type the following at a shell prompt as root : yum install cvs This installs a command line CVS client, a CVS server, and other related tools to the system. Setting Up the Default Editor When using CVS on the command line, certain commands such as cvs import or cvs commit require the user to write a short log message. To determine which text editor to start, the cvs client application first reads the contents of the environment variable USDCVSEDITOR , then reads the more general environment variable USDEDITOR , and if none of these is set, it starts vi . To persistently change the value of the USDCVSEDITOR environment variable, run the following command: echo " export CVSEDITOR= command " >> ~/.bashrc This adds the export CVSEDITOR= command line to your ~/.bashrc file. Replace command with a command that runs the editor of your choice (for example, emacs ). Note that for this change to take effect in the current shell session, you must execute the commands in ~/.bashrc by typing the following at a shell prompt: . ~/.bashrc Example 1.14. Setting up the default text editor To configure the CVS client to use Emacs as a text editor, type:

Commands:
~]USD echo "export CVSEDITOR=emacs" >> ~/.bashrc ~]USD . ~/.bashrc
7.211. Red Hat Enterprise Linux Release Notes 7.211.1. RHEA-2013:0439 - Red Hat Enterprise Linux 6.4 Release Notes Updated packages containing the Release Notes for Red Hat Enterprise Linux 6.4 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.4 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.4 Release Notes: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.4_Release_Notes/index.html Note Starting with the 6.4 release of the online Release Notes, the "Device Drivers" chapter has been moved to the online Technical Notes: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/ch-device_drivers.html

Commands:
Chapter 3. Differences from upstream OpenJDK 11 Red Hat build of OpenJDK in Red Hat Enterprise Linux (RHEL) contains a number of structural changes from the upstream distribution of OpenJDK. The Microsoft Windows version of Red Hat build of OpenJDK attempts to follow RHEL updates as closely as possible. The following list details the most notable Red Hat build of OpenJDK 11 changes: FIPS support. Red Hat build of OpenJDK 11 automatically detects whether RHEL is in FIPS mode and automatically configures Red Hat build of OpenJDK 11 to operate in that mode. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows. Cryptographic policy support. Red Hat build of OpenJDK 11 obtains the list of enabled cryptographic algorithms and key size constraints from RHEL. These configuration components are used by the Transport Layer Security (TLS) encryption protocol, the certificate path validation, and any signed JARs. You can set different security profiles to balance safety and compatibility. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows. Red Hat build of OpenJDK on RHEL dynamically links against native libraries such as zlib for archive format support and libjpeg-turbo , libpng , and giflib for image support. RHEL also dynamically links against Harfbuzz and Freetype for font rendering and management. The src.zip file includes the source for all the JAR libraries shipped with Red Hat build of OpenJDK. Red Hat build of OpenJDK on RHEL uses system-wide timezone data files as a source for timezone information. Red Hat build of OpenJDK on RHEL uses system-wide CA certificates. Red Hat build of OpenJDK on Microsoft Windows includes the latest available timezone data from RHEL. Red Hat build of OpenJDK on Microsoft Windows uses the latest available CA certificate from RHEL. Additional resources For more information about detecting if a system is in FIPS mode, see the Improve system FIPS detection example on the Red Hat RHEL Planning Jira. For more information about cryptographic policies, see Using system-wide cryptographic policies .

Commands: