mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Authentication and Interoperability Apache Modules for External Authentication A set of Apache modules was added to Red Hat Enterprise Linux 6.6 as a Technology Preview. The mod_authnz_pam , mod_intercept_form_submit , and mod_lookup_identity Apache modules in the respective packages can be used by Web applications to achieve tighter interaction with external authentication and identity sources, such as Identity Management in Red Hat Enterprise Linux. Simultaneous maintaining of TGTs for multiple KDCs Kerberos version 1.10 added a new cache storage type, DIR:, which allows Kerberos to maintain Ticket Granting Tickets (TGTs) for multiple Key Distribution Centers (KDCs) simultaneously and auto-select between them when negotiating with Kerberized resources. Red Hat Enterprise Linux 6.4 and later includes SSSD enhanced to allow the users to select the DIR: cache for users that are logging in using SSSD. This feature is introduced as a Technology Preview. Package: sssd Cross-Forest Kerberos Trust Functionality in Identity Management The Cross-Forest Kerberos Trust functionality provided by Identity Management (IdM) is included as a Technology Preview. This feature allows to create a trust relationship between an IdM and an Active Directory (AD) domain. This means that users from the AD domain can access resources and services from the IdM domain with their AD credentials. No data needs to be synchronized between the IdM and AD domain controllers; AD user are always authenticated against the AD domain controller and information about users is looked up without the need for synchronization. This feature is provided by the optional ipa-server-trust-ad package. This package depends on features which are only available in samba4 . Because samba4-* packages conflicts with the corresponding samba-* packages, all samba-* packages must be removed before ipa-server-trust-ad can be installed. When the ipa-server-trust-ad package is installed, the ipa-adtrust-install utility must be run on all IdM servers and replicas to enable IdM to handle trusts. When this is done, a trust can be established from the command line using the ipa trust-add command or the IdM web UI. For more information, see the Identity Management Guide for Red Hat Enterprise Linux . Note that Red Hat recommends to connect Red Hat Enterprise Linux 6 IdM clients to a Red Hat Enterprise Linux 7 IdM server for cross-forest trust capability. Trusts are fully supported on servers running Red Hat Enterprise Linux 7. Configuration with Red Hat Enterprise Linux 6 clients connected to a Red Hat Enterprise Linux 7 server for cross-forest trust is fully supported as well. In such setups, it is recommended to use the latest version of Red Hat Enterprise Linux 6 on the client side and the latest version of Red Hat Enterprise Linux 7 on the server side. Packages: ipa and samba

Commands:
5.2. Retrieving the Results After building the Infinispan Query, it can be executed in the same way as a HQL or Criteria query. The same paradigm and object semantic apply to Lucene Query query and all the common operations like list() . Report a bug 5.2.1. Performance Considerations list() can be used to receive a reasonable number of results (for example when using pagination) and to work on them all. list() works best if the batch-size entity is correctly set up. If list() is used, the Query Module processes all Lucene Hits elements within the pagination. Report a bug 5.2.2. Result Size Some use cases require information about the total number of matching documents. Consider the following examples: Retrieving all matching documents is costly in terms of resources. The Lucene-based Query API retrieves all matching documents regardless of pagination parameters. Since it is costly to retrieve all the matching documents, the Lucene-based Query API can retrieve the total number of matching documents regardless of the pagination parameters. All matching elements are retrieved without triggering any object loads. Example 5.20. Determining the Result Size of a Query The number of results is an approximation if the index is not correctly synchronized with the database. An ansychronous cluster is an example of this scenario. Report a bug 5.2.3. Understanding Results Luke can be used to determine why a result appears (or does not appear) in the expected query result. The Query Module also offers the Lucene Explanation object for a given result (in a given query). This is an advanced class. Access the Explanation object as follows: cacheQuery.explain(int) method This method requires a document ID as a parameter and returns the Explanation object. Note In terms of resources, building an explanation object is as expensive as running the Lucene query. Do not build an explanation object unless it is necessary for the implementation. Report a bug

Commands:
CacheQuery cacheQuery = Search.getSearchManager(cache).getQuery(luceneQuery, Book.class); //return the number of matching books without loading a single one assert 3245 == query.getResultSize(); CacheQuery cacheQueryLimited = Search.getSearchManager(cache).getQuery(luceneQuery, Book.class); query.maxResults(10); List results = query.list(); assert 10 == results.size() //return the total number of matching books regardless of pagination assert 3245 == query.getResultSize();
Appendix A. Revision History Revision History Revision 4-2 Wed Mar 8 2017 Steven Levine Version for 6.9 GA publication. Revision 4-1 Fri Dec 16 2016 Steven Levine Version for 6.9 Beta publication. Revision 3-5 Wed Apr 27 2016 Steven Levine Preparing document for 6.8 GA publication. Revision 3-4 Wed Mar 9 2016 Steven Levine Initial revision for Red Hat Enterprise Linux 6.8 Beta release Revision 2-2 Wed Jul 8 2015 Steven Levine Initial revision for Red Hat Enterprise Linux 6.7 Revision 2-1 Thu Apr 16 2015 Steven Levine Initial revision for Red Hat Enterprise Linux 6.7 Beta release Revision 1-13 Wed Oct 8 2014 Steven Levine Initial revision for Red Hat Enterprise Linux 6.6 Revision 1-11 Thu Aug 7 2014 Steven Levine Initial revision for Red Hat Enterprise Linux 6.6 Beta release Revision 1-9 Wed Nov 20 2013 John Ha Initial revision for Red Hat Enterprise Linux 6.5 Revision 1-4 Mon Nov 28 2012 John Ha Initial revision for Red Hat Enterprise Linux 6.5 Beta release Revision 1-2 Mon Nov 28 2012 John Ha Initial revision for Red Hat Enterprise Linux 6.4 Beta release

Commands:
Chapter 9. Deprecated features This section describes the deprecated features introduced in Red Hat OpenShift Data foundation 4.18. 9.1. Holder pods in OpenShift Data Foundation Multus Due to the recurring maintenance impact of holder pods during upgrade (holder pods are present when Multus is enabled), holder pods are deprecated. Because of this, holder pods must be removed before upgrading the cluster to 4.18 or risk PVCs not working correctly. Complete the procedure documented in the article link: Disabling Multus holder pods to disable and remove holder pods. Be aware that this disabling procedure is time consuming, and it is critical to complete the process before ODF is upgraded to 4.18.

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-2024:0231 RHSA-2024:0232 RHSA-2024:0233 RHSA-2024:0234 RHSA-2024:0235 RHSA-2024:0237 RHSA-2024:0239 RHSA-2024:0266 Revised on 2024-05-09 17:32:49 UTC

Commands:
Chapter 4. Performing maintenance on Compute nodes and Controller nodes with Instance HA To perform maintenance on a Compute node or a Controller node with Instance HA, stop the node by setting it in standby mode and disabling the Pacemaker resources on the node. After you complete the maintenance work, you start the node and check that the Pacemaker resources are healthy. Prerequisites A running overcloud with Instance HA enabled Procedure Log in to a Controller node and stop the Compute or Controller node: Important You must log in to a different node from the node you want to stop. Disable the Pacemaker resources on the node: Perform any maintenance work on the node. Restore the IPMI connection and start the node. Wait until the node is ready before proceeding. Enable the Pacemaker resources on the node and start the node: If you set the node to maintenance mode, source the credential file for your undercloud and unset the node from maintenance mode: Verification Check that the Pacemaker resources are active and healthy: If any Pacemaker resources fail to start during the startup process, run the pcs resource cleanup command to reset the status and the fail count of the resource. If you evacuated instances from a Compute node before you stopped the node, check that the instances are migrated to a different node:

Commands:
pcs node standby <node UUID>
pcs resource disable <ocf::pacemaker:remote on the node>
pcs resource enable <ocf::pacemaker:remote on the node> pcs node unstandby <node UUID>
source stackrc openstack baremetal node maintenance unset <baremetal node UUID>
pcs status
openstack server list --long nova migration-list
5.43. cvs 5.43.1. RHBA-2012:1302 - cvs bug fix update An updated cvs package that fixes two bugs is now available for Red Hat Enterprise Linux 6. [Update 19 November 2012] The file list of this advisory was updated to move the new cvs-inetd package from the base repository to the optional repository in the Client and HPC Node variants. No changes have been made to the packages themselves. The Concurrent Versions System (CVS) is a version control system that can record the history of your files. CVS only stores the differences between versions, instead of every version of every file you have ever created. CVS also keeps a log of who, when, and why changes occurred. * Prior to this update, the C shell (csh) did not set the CVS_RSH environment variable to "ssh" and the remote shell (rsh) was used instead when the users accessed a remote CVS server. As a consequence, the connection was vulnerable to attacks because the remote shell is not encrypted or not necessarily enabled on every remote server. The cvs.csh script now uses valid csh syntax and the CVS_RSH environment variable is properly set at log-in. (BZ#671145) * Prior to this update, the xinetd package was not a dependency of the cvs package. As a result, the CVS server was not accessible through network. With this update, the cvs-inetd package, which contains the CVS inetd configuration file, ensures that the xinetd package is installed as a dependency and the xinetd daemon is available on the system. (BZ#695719) Bug Fixes BZ# 671145 Prior to this update, the C shell (csh) did not set the CVS_RSH environment variable to "ssh" and the remote shell (rsh) was used instead when the users accessed a remote CVS server. As a consequence, the connection was vulnerable to attacks because the remote shell is not encrypted or not necessarily enabled on every remote server. The cvs.csh script now uses valid csh syntax and the CVS_RSH environment variable is properly set at log-in. BZ# 695719 Prior to this update, the xinetd package was not a dependency of the cvs package. As a result, the CVS server was not accessible through network. With this update, the cvs-inetd package, which contains the CVS inetd configuration file, ensures that the xinetd package is installed as a dependency and the xinetd daemon is available on the system. All users of cvs are advised to upgrade to these updated packages, which fix these bugs.

Commands:
OperatorHub APIs OpenShift Container Platform 4.17 Reference guide for OperatorHub APIs Red Hat OpenShift Documentation Team

Commands:
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
// other fields }
8.70. iotop 8.70.1. RHBA-2013:1719 - iotop bug fix update An updated iotop package that fixes several bugs is now available for Red Hat Enterprise Linux 6. The iotop package provides a program with a UI similar to the "top" utility. The program watches input-output (I/O) usage information output by the Linux kernel and displays a table of current I/O usage by processes on the system. Bug Fixes BZ# 746240 , BZ# 908149 Previously, the iotop utility terminated unexpectedly when it was run by a non-root user. This was because a recently-applied patch in CVE-2011-2494 made I/O statistics from the taskstats kernel subsystem accessible only to root users, and iotop did not anticipate that its "taskstats" call could fail when run by a non-root user. This update adds permission checks to iotop, and when the user does not have the necessary permissions, iotop exits with an explanation that root privileges are now required. BZ# 826875 Previously, the iotop utility did not handle platform strings correctly. Consequently, the iotop command could not show the I/O scheduling class and its priority ("PRIO") column on 64-bit PowerPC systems properly. With this update, the bug has been fixed so that the iotop command now shows the "PRIO" column on 64-bit PowerPC systems as expected. BZ# 849559 When an invalid locale was set, the iotop utility failed to start with the following traceback error: locale.Error: unsupported locale setting With this update, the underlying source code has been modified. As a result, when an invalid locale is set, the default locale is used instead and a warning about this change is returned. Users of iotop are advised to upgrade to this updated package, which fixes these bugs.

Commands:
2.2. Client NSS Database Initialization On Red Hat Certificate System, certain interfaces may need to access the server using TLS client certificate authentication (mutual authentication). Before performing server-side admin tasks, you need to: Prepare an NSS database for the client. This can be a new database or an existing one. Import the CA certificate chain and trust them. Have a certificate and corresponding key. They can be generated in the NSS database or imported from somewhere else, such as from a PKCS #12 file. Based on the utility, you need to initialize the NSS database accordingly. See: Section 2.5.1.1, "pki CLI Initialization" Section 2.3.1, " pkiconsole Initialization" Section 2.4.1, "Browser Initialization"

Commands:
B.2. The lvmconfig Command You can display the current LVM configuration, or save the configuration to a file, with the lvmconfig command. The lvmconfig command displays the LVM configuration information after loading the /etc/lvm/lvm.conf file and any other configuration files. There are a variety of features that the lvmconfig command provides, including the following; You can dump the current lvm configuration merged with any tag configuration files. You can dump all current configuration settings for which the values differ from the defaults. You can dump all new configuration settings introduced in the current LVM version, in a specific LVM version. You can dump all profilable configuration settings, either in their entirety or separately for command and metadata profiles. For information on LVM profiles see Section B.3, "LVM Profiles" . You can dump only the configuration settings for a specific version of LVM. You can validate the current configuration. For a full list of supported features and information on specifying the lvmconfig options, see the lvmconfig man page.

Commands:
Chapter 4. Finding more information The following table includes deployment references for Red Hat OpenStack Platform (RHOSP) components. For additional RHOSP documentation, see Product Documentation for Red Hat OpenStack Platform 17.1 . Component Reference Red Hat Enterprise Linux Red Hat OpenStack Platform 17.1 is supported on Red Hat Enterprise Linux 8.4. For information about installing Red Hat Enterprise Linux, see Product Documentation for Red Hat Enterprise Linux 8 . Red Hat OpenStack Platform To install OpenStack components and their dependencies, use RHOSP director. Director uses a basic OpenStack undercloud to provision and manage the OpenStack nodes in the final overcloud. Be aware that you need one extra host machine for the installation of the undercloud, in addition to the environment necessary for the deployed overcloud. For more information, see the Installing and managing Red Hat OpenStack Platform with director guide. High Availability For the configuration of additional high availability components, for example, HAProxy, see the Managing high availability services guide. For information about configuring live migration, see Migrating virtual machine instances between Compute nodes in the Configuring the Compute service for instance creation guide. Load-balancing The OpenStack Load-balancing service (octavia) provides a load balancing implementation for RHOSP director installations. For more information, see the Configuring load balancing as a service guide. Pacemaker Pacemaker is integrated into Red Hat Enterprise Linux as an add-on. To configure Red Hat Enterprise Linux for high availability, see the Configuring and managing high availability clusters guide.

Commands:
Chapter 2. Components 2.1. AMQP clients AMQ Clients includes a suite of AMQP 1.0 messaging APIs. AMQP is an ISO-standard, general-purpose messaging protocol with rich messaging capabilities. AMQ Broker and AMQ Interconnect offer AMQP 1.0 support and therefore interoperate with any AMQP 1.0 client. AMQ C++ AMQ JavaScript AMQ JMS (Java) AMQ .NET AMQ Python AMQ Ruby 2.2. JMS clients AMQ Clients offers multiple implementations of the widely used Java Message Service (JMS) API. AMQ JMS - AMQ JMS provides full AMQP 1.0 support and works with any AMQ AMQP 1.0 server or service. AMQ Core Protocol JMS - To support existing applications based on the ActiveMQ Artemis Core protocol, AMQ includes the AMQ Core Protocol JMS client. AMQ OpenWire JMS - To support existing applications based on A-MQ 6, AMQ 7 includes the AMQ OpenWire JMS client. 2.3. Adapters and libraries AMQ Clients includes components for integrating with other platforms and components. AMQ JMS Pool - To support efficient use of JMS resources, AMQ includes the AMQ JMS Pool library. It enables reuse of connection resources beyond the standard lifecycle defined by the JMS API. AMQ Spring Boot Starter - AMQ Spring Boot Starter enables you to build standalone Spring applications that use AMQP 1.0 messaging. 2.4. Component compatibility The following table lists the supported languages, platforms, protocols, and servers for the AMQ Clients components. Component Languages Platforms Protocols Servers and services AMQ C++ C++ Linux, Windows AMQP 1.0 AMQ Broker, AMQ Interconnect, and A-MQ 6 AMQ JavaScript JavaScript Linux, Windows, browsers AMQP 1.0 AMQ Broker, AMQ Interconnect, and A-MQ 6 AMQ JMS Java JVM AMQP 1.0 AMQ Broker, AMQ Interconnect, and A-MQ 6 AMQ .NET C# Linux, Windows AMQP 1.0 AMQ Broker, AMQ Interconnect, and A-MQ 6 AMQ Python Python Linux, Windows AMQP 1.0 AMQ Broker, AMQ Interconnect, and A-MQ 6 AMQ Ruby Ruby Linux AMQP 1.0 AMQ Broker, AMQ Interconnect, and A-MQ 6 AMQ Spring Boot Starter Java JVM AMQP 1.0 AMQ Broker, AMQ Interconnect, and A-MQ 6 AMQ Core Protocol JMS Java JVM Core Protocol AMQ Broker and A-MQ 6 AMQ OpenWire JMS Java JVM OpenWire AMQ Broker and A-MQ 6 AMQ JMS Pool Java JVM - - For more information, see Red Hat AMQ 7 Supported Configurations .

Commands:
4.11. Configuring Fencing for Redundant Power Supplies When configuring fencing for redundant power supplies, the cluster must ensure that when attempting to reboot a host, both power supplies are turned off before either power supply is turned back on. If the node never completely loses power, the node may not release its resources. This opens up the possibility of nodes accessing these resources simultaneously and corrupting them. Prior to Red Hat Enterprise Linux 6.8, you needed to explicitly configure different versions of the devices which used either the 'on' or 'off' actions. Since Red Hat Enterprise Linux 6.8, it is now only required to define each device once and to specify that both are required to fence the node, as in the following example.

Commands:
pcs stonith create apc1 fence_apc_snmp ipaddr=apc1.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2" pcs stonith create apc2 fence_apc_snmp ipaddr=apc2.example.com login=user passwd='7a4D#1j!pz864' pcmk_host_map="node1.example.com:1;node2.example.com:2" pcs stonith level add 1 node1.example.com apc1,apc2 pcs stonith level add 1 node2.example.com apc1,apc2