mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Red Hat build of OpenJDK 21 overview OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in four versions: 8u, 11u, 17u, and 21u. Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.

Commands:
16.6. Displaying Tiering Status Information (Deprecated) Warning Tiering is considered deprecated as of Red Hat Gluster Storage 3.5. Red Hat no longer recommends its use, and does not support tiering in new deployments and existing deployments that upgrade to Red Hat Gluster Storage 3.5.3. The status command displays the tiering volume information. # gluster volume tier VOLNAME status For example,

Commands:
gluster volume tier test-volume status Node Promoted files Demoted files Status --------- --------- --------- --------- localhost 1 5 in progress server1 0 2 in progress Tiering Migration Functionality: test-volume: success
1.3. Clustering Support for redundant ring for standalone Corosync, BZ# 722469 Red Hat Enterprise Linux 6.2 introduces support for redundant ring with autorecovery feature as a Technology Preview. Refer to Section 2.7, "Clustering" for a list of known issues associated with this Technology Preview. corosync-cpgtool, BZ# 688260 The corosync-cpgtool now specifies both interfaces in a dual ring configuration. This feature is a Technology Preview. Disabling rgmanager in /etc/cluster.conf, BZ# 723925 As a consequence of converting the /etc/cluster.conf configuration file to be used by pacemaker , rgmanager must be disabled. The risk of not doing this is high; after a successful conversion, it would be possible to start rgmanager and pacemaker on the same host, managing the same resources. Consequently, Red Hat Enterprise Linux 6.2 includes a feature (as a Technology Preview) that forces the following requirements: rgmanager must refuse to start if it sees the <rm disabled="1"> flag in /etc/cluster.conf . rgmanager must stop any resources and exit if the <rm disabled="1"> flag appears in /etc/cluster.conf during a reconfiguration. pacemaker, BZ# 456895 Pacemaker, a scalable high-availability cluster resource manager, is included in Red Hat Enterprise Linux 6 as a Technology Preview. Pacemaker is not fully integrated with the Red Hat cluster stack.

Commands:
7.107. ledmon 7.107.1. RHBA-2013:0479 - ledmon bug fix and enhancement update Updated ledmon packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The ledmon and ledctl are user space applications designed to control LEDs associated with each slot in an enclosure or a drive bay. There are two types of system: 2-LED system (Activity LED, Status LED) and 3-LED system (Activity LED, Locate LED, Fail LED). User must have root privileges to use this application. Note The ledmon package has been upgraded to upstream version 0.72., which provides a number of bug fixes and enhancements over the version. (BZ#817974) Users of ledmon are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
6.7. Insufficient Free Extents for a Logical Volume You may get the error message "Insufficient free extents" when creating a logical volume when you think you have enough extents based on the output of the vgdisplay or vgs commands. This is because these commands round figures to 2 decimal places to provide human-readable output. To specify exact size, use free physical extent count instead of some multiple of bytes to determine the size of the logical volume. The vgdisplay command, by default, includes this line of output that indicates the free physical extents. Alternately, you can use the vg_free_count and vg_extent_count arguments of the vgs command to display the free extents and the total number of extents. With 8780 free physical extents, you can run the following command, using the lower-case l argument to use extents instead of bytes: This uses all the free extents in the volume group. Alternately, you can extend the logical volume to use a percentage of the remaining free space in the volume group by using the -l argument of the lvcreate command. For information, see Section 4.4.1.1, "Creating Linear Volumes" .

Commands:
vgdisplay --- Volume group --- Free PE / Size 8780 / 34.30 GB
vgs -o +vg_free_count,vg_extent_count VG #PV #LV #SN Attr VSize VFree Free #Ext testvg 2 0 0 wz--n- 34.30G 34.30G 8780 8780
lvcreate -l8780 -n testlv testvg
vgs -o +vg_free_count,vg_extent_count VG #PV #LV #SN Attr VSize VFree Free #Ext testvg 2 1 0 wz--n- 34.30G 0 0 8780
4.7. Authentication SSSD currently does not support eDirectory account lockout policies. when installing a replica (using the ipa-replica-install command), GSSAPI errors similar to the following might be returned: These messages can be safely ignored.

Commands:
[07/Apr/2011:10:46:23 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) [07/Apr/2011:10:46:23 -0400] NSMMReplicationPlugin - agmt="cn=meToipaqa64vmb.testrelm" (ipaqa64vmb:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found))
Chapter 1. Operators overview Operators are among the most important components of OpenShift Container Platform. They are the preferred method of packaging, deploying, and managing services on the control plane. They can also provide advantages to applications that users run. Operators integrate with Kubernetes APIs and CLI tools such as kubectl and the OpenShift CLI ( oc ). They provide the means of monitoring applications, performing health checks, managing over-the-air (OTA) updates, and ensuring that applications remain in your specified state. Operators are designed specifically for Kubernetes-native applications to implement and automate common Day 1 operations, such as installation and configuration. Operators can also automate Day 2 operations, such as autoscaling up or down and creating backups. All of these activities are directed by a piece of software running on your cluster. While both follow similar Operator concepts and goals, Operators in OpenShift Container Platform are managed by two different systems, depending on their purpose: Cluster Operators Managed by the Cluster Version Operator (CVO) and installed by default to perform cluster functions. Optional add-on Operators Managed by Operator Lifecycle Manager (OLM) and can be made accessible for users to run in their applications. Also known as OLM-based Operators . 1.1. For developers As an Operator author, you can perform the following development tasks for OLM-based Operators: Install Operator SDK CLI . Create Go-based Operators , Ansible-based Operators , and Helm-based Operators . Use Operator SDK to build, test, and deploy an Operator . Install and subscribe an Operator to your namespace . Create an application from an installed Operator through the web console . Additional resources Machine deletion lifecycle hook examples for Operator developers 1.2. For administrators As a cluster administrator, you can perform the following administrative tasks for OLM-based Operators: Manage custom catalogs . Allow non-cluster administrators to install Operators . Install an Operator from OperatorHub . View Operator status . Manage Operator conditions . Upgrade installed Operators . Delete installed Operators . Configure proxy support . Using Operator Lifecycle Manager in disconnected environments . For information about the cluster Operators that Red Hat provides, see Cluster Operators reference . 1.3. steps To understand more about Operators, see What are Operators?

Commands:
8.156. openldap 8.156.1. RHBA-2014:1426 - openldap bug fix and enhancement update Updated openldap packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. OpenLDAP is an open source suite of LDAP (Lightweight Directory Access Protocol) applications and development tools. LDAP is a set of protocols for accessing directory services (usually phone book style information, but other information is possible) over the Internet, similar to the way DNS (Domain Name System) information is propagated over the Internet. The openldap package contains configuration files, libraries, and documentation for OpenLDAP. This update also fixes the following bug: Note The openldap packages have been upgraded to upstream version 2.4.39, which provides a number of bug fixes and enhancements over the version. Specifically, Memory-mapped database library (LMDB) support in OpenLDAP has been enabled. (BZ# 923680 ) This update also fixes the following bug: Users of openldap are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
9.7. Using Rules to Determine Resource Location You can use a rule to determine a resource's location with the following command. The expression can be one of the following: defined|not_defined attribute attribute lt|gt|lte|gte|eq|ne value date [start= start ] [end= end ] operation=gt|lt|in-range date-spec date_spec_options

Commands:
pcs constraint location resource_id rule [rule_id] [role=master|slave] [score= score expression ]
18.12.10.2. VLAN (802.1Q) Protocol ID: vlan Rules of this type should go either into the root or vlan chain. Table 18.4. VLAN protocol types Attribute Name Datatype Definition srcmacaddr MAC_ADDR MAC address of sender srcmacmask MAC_MASK Mask applied to MAC address of sender dstmacaddr MAC_ADDR MAC address of destination dstmacmask MAC_MASK Mask applied to MAC address of destination vlan-id UINT16 (0x0-0xfff, 0 - 4095) VLAN ID encap-protocol UINT16 (0x03c-0xfff), String Encapsulated layer 3 protocol ID, valid strings are arp, ipv4, ipv6 comment STRING text string up to 256 characters

Commands:
4.100. irqbalance 4.100.1. RHBA-2012:0552 - irqbalance bug fix update Updated irqbalance packages that fix one bug are now available for Red Hat Enterprise Linux 6. The irqbalance package provides a daemon that evenly distributes interrupt request (IRQ) load across multiple CPUs for enhanced performance. Bug Fix BZ# 817873 The irqbalance daemon assigns each interrupt source in the system to a "class", which represents the type of the device (for example Networking, Storage or Media). Previously, irqbalance used the IRQ handler names from the /proc/interrupts file to decide the source class, which caused irqbalance to not recognize network interrupts correctly. As a consequence, systems using biosdevname NIC naming did not have their hardware interrupts distributed and pinned as expected. With this update, the device classification mechanism has been improved, and so ensures a better interrupts distribution. All users of irqbalance are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 24. Set Up the L1 Cache 24.1. About the L1 Cache The Level 1 (or L1 ) cache stores remote cache entries after they are initially accessed, preventing unnecessary remote fetch operations for each subsequent use of the same entries. The L1 cache is only available when Red Hat JBoss Data Grid's cache mode is set to distribution. In other cache modes any configuration related to the L1 cache is ignored. When caches are configured with distributed mode, the entries are evenly distributed between all clustered caches. Each entry is copied to a desired number of owners, which can be less than the total number of caches. As a result, the system's scalability is improved but also means that some entries are not available on all nodes and must be fetched from their owner node. In this situation, configure the Cache component to use the L1 Cache to temporarily store entries that it does not own to prevent repeated fetching for subsequent uses. Each time a key is updated an invalidation message is generated. This message is multicast to each node that contains data that corresponds to current L1 cache entries. The invalidation message ensures that each of these nodes marks the relevant entry as invalidated. Also, when the location of an entry changes in the cluster, the corresponding L1 cache entry is invalidated to prevent outdated cache entries. Report a bug

Commands:
7.232. xcb-util 7.232.1. RHBA-2015:1318 - xcb-util bug fix update Updated xcb-util packages that fix one bug are now available for Red Hat Enterprise Linux 6. The xcb-util packages provide a number of libraries which utilize libxcb, the core X protocol library, and some of the extension libraries. Bug Fix BZ# 1167486 The libxcb-icccm.so.1 file was replaced with libxcb-icccm.so.4 in the upgrade of the xcb-util packages. Consequently, packages that required the old file could not be installed anymore, or if such packages were installed, xcb-util could not be upgraded. With this update, the libxcb-icccm.so.1 file has been made available again in a new subpackage called compat-xcb-util. As a result, the dependency on libxcb-icccm.so.1 is satisfied. Users of xcb-util are advised to upgrade to these updated packages, which fix this bug.

Commands:
33.7. Managing Reverse DNS Zones A reverse DNS zone can be identified in the following two ways: By the zone name, in the format reverse_ipv4_address .in-addr.arpa or reverse_ipv6_address .ip6.arpa . The reverse IP address is created by reversing the order of the components of the IP address. For example, if the IPv4 network is 192.0.2.0/24 , the reverse zone name is 2.0.192.in-addr.arpa. (with the trailing period). By the network address, in the format network_ip_address / subnet_mask_bit_count To create the reverse zone by its IP network, set the network information to the (forward-style) IP address, with the subnet mask bit count. The bit count must be a multiple of eight for IPv4 addresses or a multiple of four for IPv6 addresses. Adding a Reverse DNS Zone in the Web UI Open the Network Services tab, and select the DNS subtab, followed by the DNS Zones section. Figure 33.30. DNS Zone Management Click Add at the top of the list of all zones. Figure 33.31. Adding a Reverse DNS Zone Fill in the zone name or the reverse zone IP network. For example, to add a reverse DNS zone by the zone name: Figure 33.32. Creating a Reverse Zone by Name Alternatively, to add a reverse DNS zone by the reverse zone IP network: Figure 33.33. Creating a Reverse Zone by IP Network The validator for the Reverse zone IP network field warns you about an invalid network address during typing. The warning will disappear once you enter the full network address. Click Add to confirm the new reverse zone. Adding a Reverse DNS Zone from the Command Line To create a reverse DNS zone from the command line, use the ipa dnszone-add command. For example, to create the reverse zone by the zone name: Alternatively, to create the reverse zone by the IP network: Other Management Operations for Reverse DNS Zones Section 33.4, "Managing Master DNS Zones" describes other zone management operations, some of which are also applicable to reverse DNS zone management, such as editing or disabling and enabling DNS zones.

Commands:
[user@server]USD ipa dnszone-add 2.0.192.in-addr.arpa.
[user@server ~]USD ipa dnszone-add --name-from-ip= 192.0.2.0/24
Chapter 1. Overview Due to the growing demands on availability, one copy of data is not enough. To ensure business continuity, a reliable and highly available architecture must replicate data across more than just one system. Using multitarget system replication, the primary system can replicate data changes to more than one secondary system. For more information, see SAP HANA Multitarget System Replication . This document describes how to configure a replication site for disaster recovery using SAP HANA Multitarget System Replication on a 2-node cluster, installed as described in Automating SAP HANA Scale-Up System Replication using the RHEL HA Add-On . A sample configuration looks like this: The initial setup is as follows: Replicate Primary site 1 (DC1) to Secondary site 2 (DC2) Replicate Primary site 1 (DC1) to Secondary site 3 (DC3) If the primary fails, the primary switches to secondary site 2 (DC2) and the former primary site 1 (DC1) will become the secondary site. When failover occurs, this solution ensures that the configured primary site is switched at the third DR site as well. The configuration after failover is as follows: Primary running on DC2 Secondary running on DC1 (synced from DC2) Secondary running on DC3 (synced from DC2) The SAP HANA instance on remotehost3 will be automatically re-registered to the new primary as long as this instance is up and running during the failover. This document also describes the example of switching the primary database to the third site. Please note that further network configuration is required for the connection of the clients to the database. This is not within the scope of this document. For further information, please check the following: SAP HANA Administration Guide for SAP HANA Platform How to Setup SAP HANA Multi-Target System Replication

Commands:
16.2. The Graphical Installation Program User Interface If you have used a graphical user interface (GUI) before, you are already familiar with this process; use your mouse to navigate the screens, click buttons, or enter text fields. You can also navigate through the installation using the keyboard. The Tab key allows you to move around the screen, the Up and Down arrow keys to scroll through lists, + and - keys expand and collapse lists, while Space and Enter selects or removes from selection a highlighted item. You can also use the Alt + X key command combination as a way of clicking on buttons or making other screen selections, where X is replaced with any underlined letter appearing within that screen. If you would like to use a graphical installation with a system that does not have that capability, such as a partitioned system, you can use VNC or display forwarding. Both the VNC and display forwarding options require an active network during the installation and the use of boot time arguments. For more information on available boot time options, refer to Chapter 28, Boot Options Note If you do not wish to use the GUI installation program, the text mode installation program is also available. To start the text mode installation program, use the following command at the yaboot: prompt: Refer to Section 14.1, "The Boot Menu" for a description of the Red Hat Enterprise Linux boot menu and to Section 15.1, "The Text Mode Installation Program User Interface" for a brief overview of text mode installation instructions. It is highly recommended that installs be performed using the GUI installation program. The GUI installation program offers the full functionality of the Red Hat Enterprise Linux installation program, including LVM configuration which is not available during a text mode installation. Users who must use the text mode installation program can follow the GUI installation instructions and obtain all needed information.

Commands:
linux text
Chapter 2. Non-interactively selecting a system-wide Red Hat build of OpenJDK version on RHEL If you have multiple versions of Red Hat build of OpenJDK installed on RHEL, you can select the default Red Hat build of OpenJDK version to use system-wide in a non-interactive way. This is useful for administrators who have root privileges on a Red Hat Enterprise Linux system and need to switch the default Red Hat build of OpenJDK on many systems in an automated way. Note If you do not have root privileges, you can select an Red Hat build of OpenJDK version by configuring the JAVA_HOME environment variable . Prerequisites You must have root privileges on the system. Multiple versions of Red Hat build of OpenJDK were installed using the yum package manager. Procedure Select the major Red Hat build of OpenJDK version to switch to. For example, for Red Hat build of OpenJDK 8, use java-1.8.0-openjdk. Verify that the active Red Hat build of OpenJDK version is the one you specified. Note A similar approach can be followed for javac .

Commands:
PKG_NAME=java-1.8.0-openjdk JAVA_TO_SELECT=USD(alternatives --display java | grep "family USDPKG_NAME" | cut -d' ' -f1) alternatives --set java USDJAVA_TO_SELECT
java -version openjdk version "1.8.0_242" OpenJDK Runtime Environment (build 1.8.0_242-b08) OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
7.3. Overcommitting Virtualized CPUs The KVM hypervisor supports overcommitting virtualized CPUs (vCPUs). Virtualized CPUs can be overcommitted as far as load limits of guest virtual machines allow. Use caution when overcommitting vCPUs, as loads near 100% may cause dropped requests or unusable response times. In Red Hat Enterprise Linux 7, it is possible to overcommit guests with more than one vCPU, known as symmetric multiprocessing (SMP) virtual machines. However, you may experience performance deterioration when running more cores on the virtual machine than are present on your physical CPU. For example, a virtual machine with four vCPUs should not be run on a host machine with a dual core processor, but on a quad core host. Overcommitting SMP virtual machines beyond the physical number of processing cores causes significant performance degradation, due to programs getting less CPU time than required. In addition, it is not recommended to have more than 10 total allocated vCPUs per physical processor core. With SMP guests, some processing overhead is inherent. CPU overcommitting can increase the SMP overhead, because using time-slicing to allocate resources to guests can make inter-CPU communication inside a guest slower. This overhead increases with guests that have a larger number of vCPUs, or a larger overcommit ratio. Virtualized CPUs are overcommitted best when when a single host has multiple guests, and each guest has a small number of vCPUs, compared to the number of host CPUs. KVM should safely support guests with loads under 100% at a ratio of five vCPUs (on 5 virtual machines) to one physical CPU on one single host. The KVM hypervisor will switch between all of the virtual machines, making sure that the load is balanced. For best performance, Red Hat recommends assigning guests only as many vCPUs as are required to run the programs that are inside each guest. Important Applications that use 100% of memory or processing resources may become unstable in overcommitted environments. Do not overcommit memory or CPUs in a production environment without extensive testing, as the CPU overcommit ratio and the amount of SMP are workload-dependent.

Commands: