mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 26. Probe schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaExporterSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , TlsSidecar , ZookeeperClusterSpec Property Property type Description failureThreshold integer Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. initialDelaySeconds integer The initial delay before first the health is first checked. Default to 15 seconds. Minimum value is 0. periodSeconds integer How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. successThreshold integer Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1. timeoutSeconds integer The timeout for each attempted health check. Default to 5 seconds. Minimum value is 1.

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:1822 RHSA-2023:1879 RHSA-2023:1884 RHSA-2023:1885 RHSA-2023:1890 RHSA-2023:1891 RHSA-2023:1898 RHSA-2023:1900 Revised on 2024-05-03 15:36:58 UTC

Commands:
10.5.43. IndexOptions IndexOptions controls the appearance of server generated directing listings, by adding icons, file descriptions, and so on. If Options Indexes is set (refer to Section 10.5.23, " Options " ), the Web server generates a directory listing when the Web server receives an HTTP request for a directory without an index. First, the Web server looks in the requested directory for a file matching the names listed in the DirectoryIndex directive (usually, index.html ). If an index.html file is not found, Apache HTTP Server creates an HTML directory listing of the requested directory. The appearance of this directory listing is controlled, in part, by the IndexOptions directive. The default configuration turns on FancyIndexing . This means that a user can re-sort a directory listing by clicking on column headers. Another click on the same header switches from ascending to descending order. FancyIndexing also shows different icons for different files, based upon file extensions. The AddDescription option, when used in conjunction with FancyIndexing , presents a short description for the file in server generated directory listings. IndexOptions has a number of other parameters which can be set to control the appearance of server generated directories. The IconHeight and IconWidth parameters require the server to include HTML HEIGHT and WIDTH tags for the icons in server generated webpages. The IconsAreLinks parameter combines the graphical icon with the HTML link anchor, which contains the URL link target.

Commands:
8.2. Huge Page Support This section provides information about huge page support. Introduction x86 CPUs usually address memory in 4kB pages, but they are capable of using larger pages known as huge pages . KVM guests can be deployed with huge page memory support in order to improve performance by increasing CPU cache hits against the Transaction Lookaside Buffer (TLB) . Huge pages can significantly increase performance, particularly for large memory and memory-intensive workloads. Red Hat Enterprise Linux 6 is able to more effectively manage large amounts of memory by increasing the page size through the use of huge pages. By using huge pages for a KVM guest, less memory is used for page tables and TLB misses are reduced, thereby significantly increasing performance, especially for memory-intensive situations. Transparent Huge Pages Transparent huge pages (THP) is a kernel feature that reduces TLB entries needed for an application. By also allowing all free memory to be used as cache, performance is increased. To use transparent huge pages, no special configuration in the qemu.conf file is required. Huge pages are used by default if /sys/kernel/mm/redhat_transparent_hugepage/enabled is set to always . Transparent huge pages do not prevent the use of the hugetlbfs feature. However, when hugetlbfs is not used, KVM will use transparent huge pages instead of the regular 4kB page size. Note See the Red Hat Enterprise Linux 7 Virtualization Tuning and Optimization Guide for instructions on tuning memory performance with huge pages.

Commands:
Preface Red Hat OpenShift Data Foundation 4.9 supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) bare metal clusters in connected or disconnected environments along with out-of-the-box support for proxy environments. Both internal and external OpenShift Data Foundation clusters are supported on bare metal. See Planning your deployment and Preparing to deploy OpenShift Data Foundation for more information about deployment requirements. To deploy OpenShift Data Foundation, follow the appropriate deployment process based on your requirement: Internal mode Deploy using local storage devices Deploy standalone Multicloud Object Gateway component External mode

Commands:
10.5.9.3. MaxClients MaxClients sets a limit on the total number of server processes, or simultaneously connected clients, that can run at one time. The main purpose of this directive is to keep a runaway Apache HTTP Server from crashing the operating system. For busy servers this value should be set to a high value. The server's default is set to 150 regardless of the MPM in use. However, it is not recommended that the value for MaxClients exceeds 256 when using the prefork MPM.

Commands:
Chapter 19. Registering RHEL by using Subscription Manager Post-installation, you must register your system to get continuous updates. 19.1. Registering RHEL 8 using the installer GUI You can register a Red Hat Enterprise Linux 8 by using the RHEL installer GUI. Prerequisites You have a valid user account on the Red Hat Customer Portal. See the Create a Red Hat Login page . You have a valid Activation Key and Organization id. Procedure From the Installation Summary screen, under Software , click Connect to Red Hat . Authenticate your Red Hat account using the Account or Activation Key option. Optional: In the Set System Purpose field select the Role , SLA , and Usage attribute that you want to set from the drop-down menu. At this point, your Red Hat Enterprise Linux 8 system has been successfully registered. 19.2. Registration Assistant Registration Assistant is designed to help you choose the most suitable registration option for your Red Hat Enterprise Linux environment. Additional resources For assistance with using a username and password to register RHEL with the Subscription Manager client, see the RHEL registration assistant on the Customer Portal. For assistance with registering your RHEL system to Red Hat Insights, see the Insights registration assistant on the Hybrid Cloud Console. 19.3. Registering your system using the command line You can register your Red Hat Enterprise Linux 8 subscription by using the command line. For an improved and simplified experience registering your hosts to Red Hat, use remote host configuration (RHC). The RHC client registers your system to Red Hat making your system ready for Insights data collection and enabling direct issue remediation from Insights for Red Hat Enterprise Linux. For more information, see RHC registration . Prerequisites You have an active, non-evaluation Red Hat Enterprise Linux subscription. Your Red Hat subscription status is verified. You have not previously received a Red Hat Enterprise Linux 8 subscription. You have successfully installed Red Hat Enterprise Linux 8 and logged into the system as root. Procedure Open a terminal window as a root user. Register your Red Hat Enterprise Linux system by using the activation key: When the system is successfully registered, an output similar to the following is displayed: Additional resources Using an activation key to register a system with Red Hat Subscription Manager Getting Started with RHEL System Registration

Commands:
subscription-manager register --activationkey= <activation_key_name> --org= <organization_ID>
The system has been registered with id: 62edc0f8-855b-4184-b1b8-72a9dc793b96
9.2. Configure Invalidation Mode (Remote Client-Server Mode) Invalidation mode is a clustered mode in Red Hat JBoss Data Grid. Invalidation mode can be added to any cache container using the following procedure: Procedure 9.1. The invalidation-cache Element The invalidation-cache element configures settings for the distributed cache using the following parameters: The name parameter provides a unique identifier for the cache. The mode parameter sets the clustered cache mode. Valid values are SYNC (synchronous) and ASYNC (asynchronous). The start parameter specifies whether the cache starts when the server starts up or when it is requested or deployed. If statistics are enabled at the container level, per-cache statistics can be selectively disabled for caches that do not require monitoring by setting the statistics attribute to false . Important JGroups must be appropriately configured for clustered mode before attempting to load this configuration. For details about the cache-container , locking , and transaction elements, see the appropriate chapter. Report a bug

Commands:
<cache-container name="local" default-cache="default" statistics="true"> <invalidation-cache name="default" mode="ASYNC" start="EAGER" statistics="true"> <!-- Additional configuration information here --> </invalidation-cache> </cache-container>
Chapter 9. Red Hat JBoss Data Grid as Lucene Directory Red Hat JBoss Data Grid can be used as a shared, in-memory index (Infinispan Directory) for Hibernate Search queries on a relational database. By default, Hibernate Search uses a local filesystem to store the Lucene indexes but optionally it can be configured to use JBoss Data Grid as a storage to achieve real-time replication across multiple server nodes. In the Infinispan Directory, the index is stored in memory and shared across multiple nodes. The Infinispan Directory acts as a single directory distributed across all participating nodes. An index update on one node updates the index on all the nodes. Index can be searched immediately after the node update across the cluster. The default Hibernate Search configuration replicates the data defining the index across all the nodes. Data distribution for large indexes may be enabled to consume less memory; however, this will come at a cost of locality resulting in query operations less efficient. The indexed data can also be offloaded to a CacheStore configured on each node or configure a single centralized CacheStore shared by each node. Note While enabling distribution rather than replication might save memory, the queries will be slower. Enabling a CacheStore might save even more memory, but at cost of additional performance if used for passivation. Report a bug 9.1. Configuration The directory provider is enabled by specifying it per index. If the default index is specified then all indexes will use the directory provider unless specified: hibernate.search.[default|<indexname>].directory_provider = infinispan This gives a cluster-replicated index, but the default configuration does not enable any form of permanent persistence for the index. To enable such a feature provide an Infinispan configuration file. Hibernate Search requires a CacheManager to use Infinispan. It can look up and reuse an existing CacheManager , via JNDI, or start and manage a new one. When looking up an existing CacheManager this will be provided from the Infinispan subsystem where it was originally registered; for instance, if this was registered via JBoss EAP, then JBoss EAP's Infinispan subsystem will provide the CacheManager . Note When using JNDI to register a CacheManager , it must be done using Red Hat JBoss Data Grid configuration files only. To use an existing CacheManager via JNDI (optional parameter): hibernate.search.infinispan.cachemanager_jndiname = [jndiname] To start a new CacheManager from a configuration file (optional parameter): hibernate.search.infinispan.configuration_resourcename = [infinispan configuration filename] If both the parameters are defined, JNDI will have priority. If none of these are defined, Hibernate Search will use the default Infinispan configuration which does not store the index in a persistent cache store. Report a bug

Commands:
7.9. Additional Resources For more information about the Audit system, see the following sources. Online Sources RHEL Audit System Refence: https://access.redhat.com/articles/4409591 . The Linux Audit Documentation Project page: https://github.com/linux-audit/audit-documentation/wiki . Installed Documentation Documentation provided by the audit package can be found in the /usr/share/doc/audit/ directory. Manual Pages audispd.conf (5) auditd.conf (5) ausearch-expression (5) audit.rules (7) audispd (8) auditctl (8) auditd (8) aulast (8) aulastlog (8) aureport (8) ausearch (8) ausyscall (8) autrace (8) auvirt (8)

Commands:
Chapter 5. Automating RHEL system registration with a Kickstart file You can use a Kickstart file with a system installer and an activation key to automatically register a system during the installation process. This is especially useful if you want to install and register multiple instances of RHEL. You can also use a single Kickstart file to install RHEL on multiple computers. You can put an activation key into a shared Kickstart file to authenticate the processes without exposing username and password values. Additionally, administrators can preconfigure the activation key with selected system-level features, such as system purpose attributes. When an authorized user uses the activation key to authenticate the registration process, the selected features are automatically applied to the system with a single command. Additional resources For information about registering your RHEL 9 system with Kickstart, see Registering and installing RHEL from the Content Delivery Network and Satellite . For information about registering your RHEL 8 system with Kickstart, see Registering and installing RHEL from the CDN using Kickstart . For information about registering your RHEL 7 system with Kickstart, see Automatic Installation .

Commands:
Preface Self-hosted engine installation is automated using Ansible. The installation script ( hosted-engine --deploy ) runs on an initial deployment host, and the Red Hat Virtualization Manager (or "engine") is installed and configured on a virtual machine that is created on the deployment host. The Manager and Data Warehouse databases are installed on the Manager virtual machine, but can be migrated to a separate server post-installation if required. Hosts that can run the Manager virtual machine are referred to as self-hosted engine nodes. At least two self-hosted engine nodes are required to support the high availability feature. A storage domain dedicated to the Manager virtual machine is referred to as the self-hosted engine storage domain. This storage domain is created by the installation script, so the underlying storage must be prepared before beginning the installation. See the Planning and Prerequisites Guide for information on environment options and recommended configuration. See Self-Hosted Engine Recommendations for configuration specific to a self-hosted engine environment. Table 1. Red Hat Virtualization Key Components Component Name Description Red Hat Virtualization Manager A service that provides a graphical user interface and a REST API to manage the resources in the environment. The Manager is installed on a physical or virtual machine running Red Hat Enterprise Linux. Hosts Red Hat Enterprise Linux hosts (RHEL hosts) and Red Hat Virtualization Hosts (image-based hypervisors) are the two supported types of host. Hosts use Kernel-based Virtual Machine (KVM) technology and provide resources used to run virtual machines. Shared Storage A storage service is used to store the data associated with virtual machines. Data Warehouse A service that collects configuration information and statistical data from the Manager. Self-Hosted Engine Architecture The Red Hat Virtualization Manager runs as a virtual machine on self-hosted engine nodes (specialized hosts) in the same environment it manages. A self-hosted engine environment requires one less physical server, but requires more administrative overhead to deploy and manage. The Manager is highly available without external HA management. The minimum setup of a self-hosted engine environment includes: One Red Hat Virtualization Manager virtual machine that is hosted on the self-hosted engine nodes. The RHV-M Appliance is used to automate the installation of a Red Hat Enterprise Linux 7 virtual machine, and the Manager on that virtual machine. A minimum of two self-hosted engine nodes for virtual machine high availability. You can use Red Hat Enterprise Linux hosts or Red Hat Virtualization Hosts (RHVH). VDSM (the host agent) runs on all hosts to facilitate communication with the Red Hat Virtualization Manager. The HA services run on all self-hosted engine nodes to manage the high availability of the Manager virtual machine. One storage service, which can be hosted locally or on a remote server, depending on the storage type used. The storage service must be accessible to all hosts. Figure 1. Self-Hosted Engine Red Hat Virtualization Architecture

Commands:
8.201. slapi-nis 8.201.1. RHBA-2013:1671 - slapi-nis bug fix update Updated slapi-nis packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The slapi-nis package contains the NIS server plug-in and the Schema Compatibility plug-in for use with the 389 directory server. Bug Fixes BZ# 923336 Due to a bug in the NIS Server plug-in, when multiple clients were connected to the server over stream sockets, some of these clients were disconnected earlier than expected. This bug has been fixed and clients are no longer disconnected too early in the described case. BZ# 967468 Prior to this update, the NIS Server plug-in did not release memory that was used to hold a decoded client request. Consequently, the directory server used an excessive amount of memory as it processed more requests from NIS clients. The bug has been fixed and the directory server now consumes an expected amount of memory. Users of slapi-nis are advised to upgrade to these updated packages, which fix these bugs.

Commands:
probe::signal.handle Name probe::signal.handle - Signal handler being invoked Synopsis Values regs The address of the kernel-mode stack area sig_code The si_code value of the siginfo signal name Name of the probe point sig_mode Indicates whether the signal was a user-mode or kernel-mode signal sinfo The address of the siginfo table sig_name A string representation of the signal oldset_addr The address of the bitmask array of blocked signals sig The signal number that invoked the signal handler ka_addr The address of the k_sigaction table associated with the signal

Commands:
signal.handle
Chapter 6. Encrypt at-rest swift objects By default, objects uploaded to Object Storage are stored unencrypted. Because of this, it is possible to access objects directly from the file system. This can present a security risk if disks are not properly erased before they are discarded. When you have barbican enabled, the Object Storage service (swift) can transparently encrypt and decrypt your stored (at-rest) objects. At-rest encryption is distinct from in-transit encryption in that it refers to the objects being encrypted while being stored on disk. Swift performs these encryption tasks transparently, with the objects being automatically encrypted when uploaded to swift, then automatically decrypted when served to a user. This encryption and decryption is done using the same (symmetric) key, which is stored in barbican. Note You cannot disable encryption after you have enabled encryption and added data to the swift cluster, because the data is now stored in an encrypted state. Consequently, the data will not be readable if encryption is disabled, until you re-enable encryption with the same key. 6.1. Enable at-rest encryption for swift You can enable the swift encryption capabilities by including SwiftEncryptionEnabled: True in your environment file, then re-running openstack overcloud deploy using /home/stack/overcloud_deploy.sh . Note that you still need to enable barbican, as described in the Install Barbican chapter. Confirm that swift is configured to use at-rest encryption: The result should include an entry for encryption .

Commands:
crudini --get /var/lib/config-data/puppet-generated/swift/etc/swift/proxy-server.conf pipeline-main pipeline pipeline = catch_errors healthcheck proxy-logging cache ratelimit bulk tempurl formpost authtoken keystone staticweb copy container_quotas account_quotas slo dlo versioned_writes kms_keymaster encryption proxy-logging proxy-server
7.24. clustermon 7.24.1. RHBA-2013:0469 - clustermon bug fix update Updated clustermon packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The clustermon packages provide the modclusterd daemon, which is a service for remote cluster management. Modclusterd serves as an abstraction of the cluster status that utilizes other clustermon parts exposed through conga, the Simple Network Management (SNMP), and Common Information Model (CIM). Bug Fixes BZ# 865588 Prior to this update, the dynamic library that represents the CIM provider of a cluster status was not built with all the required dependencies and therefore certain symbols could not be resolved. As a consequence, the cluster status could not be accessed via CIM. This update adds the missing dependencies to the dynamic library. Now, the cluster status is accessible as expected. BZ# 885830 Prior to this update, the size of XML-formatted cluster configuration (as in cluster.conf file) greater than 200 kB might have crashed modcluster, a program assisting the ricci daemon in handling the cluster configuration file (cluster.conf), or modclusterd, a daemon providing cluster status. This update drops this restriction and both executables no longer abort with larger configurations. All users of clustermon are advised to upgrade to these updated packages, which fix these bugs.

Commands:
1.3.2. Server Weight and Scheduling The administrator of LVS can assign a weight to each node in the real server pool. This weight is an integer value which is factored into any weight-aware scheduling algorithms (such as weighted least-connections) and helps the LVS router more evenly load hardware with different capabilities. Weights work as a ratio relative to one another. For instance, if one real server has a weight of 1 and the other server has a weight of 5, then the server with a weight of 5 gets 5 connections for every 1 connection the other server gets. The default value for a real server weight is 1. Although adding weight to varying hardware configurations in a real server pool can help load-balance the cluster more efficiently, it can cause temporary imbalances when a real server is introduced to the real server pool and the virtual server is scheduled using weighted least-connections. For example, suppose there are three servers in the real server pool. Servers A and B are weighted at 1 and the third, server C, is weighted at 2. If server C goes down for any reason, servers A and B evenly distributes the abandoned load. However, once server C comes back online, the LVS router sees it has zero connections and floods the server with all incoming requests until it is on par with servers A and B. To prevent this phenomenon, administrators can make the virtual server a quiesce server - anytime a new real server node comes online, the least-connections table is reset to zero and the LVS router routes requests as if all the real servers were newly added to the cluster.

Commands: