mtpti5iD/redhat-docs_dataset huggingface dataset:
10.4. Cluster Daemon crashes RGManager has a watchdog process that reboots the host if the main rgmanager process fails unexpectedly. This causes the cluster node to get fenced and rgmanager to recover the service on another host. When the watchdog daemon detects that the main rgmanager process has crashed then it will reboot the cluster node, and the active cluster nodes will detect that the cluster node has left and evict it from the cluster. The lower number process ID (PID) is the watchdog process that takes action if its child (the process with the higher PID number) crashes. Capturing the core of the process with the higher PID number using gcore can aid in troubleshooting a crashed daemon. Install the packages that are required to capture and view the core, and ensure that both the rgmanager and rgmanager-debuginfo are the same version or the captured application core might be unusable. 10.4.1. Capturing the rgmanager Core at Runtime There are two rgmanager processes that are running as it is started. You must capture the core for the rgmanager process with the higher PID. The following is an example output from the ps command showing two processes for rgmanager . In the following example, the pidof program is used to automatically determine the higher-numbered pid, which is the appropriate pid to create the core. The full command captures the application core for the process 22483 which has the higher pid number.

Commands:
yum -y --enablerepo=rhel-debuginfo install gdb rgmanager-debuginfo
ps aux | grep rgmanager | grep -v grep root 22482 0.0 0.5 23544 5136 ? S<Ls Dec01 0:00 rgmanager root 22483 0.0 0.2 78372 2060 ? S<l Dec01 0:47 rgmanager
gcore -o /tmp/rgmanager-USD(date '+%F_%s').core USD(pidof -s rgmanager)
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 16.2 . Component Reference Red Hat Enterprise Linux Red Hat OpenStack Platform 16.2 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 Director Installation and Usage guide. High Availability For the configuration of additional high availability components, for example, HAProxy, see the High Availability Deployment and Usage 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-as-a-Service (LBaaS) version 2 implementation for RHOSP director installations. For more information, see the Using Octavia for 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:
7.282. xorg-x11-drv-nouveau 7.282.1. RHBA-2013:0304 - xorg-x11-drv-nouveau bug fix and enhancement update Updated xorg-x11-drv-nouveau packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-nouveau package provides the X.Org X11 noveau video driver for NVIDIA graphics chipsets. Note The xorg-x11-drv-nouveau package has been upgraded to upstream version 1.0.1, which provides a number of bug fixes and enhancements over the version. (BZ#835245) Users of xorg-x11-drv-nouveau are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 135. AutoRestart schema reference Used in: KafkaConnectorSpec , KafkaMirrorMaker2ConnectorSpec Full list of AutoRestart schema properties Configures automatic restarts for connectors and tasks that are in a FAILED state. When enabled, a back-off algorithm applies the automatic restart to each failed connector and its tasks. An incremental back-off interval is calculated using the formula n * n + n where n represents the number of restarts. This interval is capped at a maximum of 60 minutes. Consequently, a restart occurs immediately, followed by restarts after 2, 6, 12, 20, 30, 42, 56 minutes, and then at 60-minute intervals. By default, Streams for Apache Kafka initiates restarts of the connector and its tasks indefinitely. However, you can use the maxRestarts property to set a maximum on the number of restarts. If maxRestarts is configured and the connector still fails even after the final restart attempt, you must then restart the connector manually. For Kafka Connect connectors, use the autoRestart property of the KafkaConnector resource to enable automatic restarts of failed connectors and tasks. Enabling automatic restarts of failed connectors for Kafka Connect apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true If you prefer, you can also set a maximum limit on the number of restarts. Enabling automatic restarts of failed connectors for Kafka Connect with limited number of restarts apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true maxRestarts: 10 For MirrorMaker 2, use the autoRestart property of connectors in the KafkaMirrorMaker2 resource to enable automatic restarts of failed connectors and tasks. Enabling automatic restarts of failed connectors for MirrorMaker 2 apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mm2-cluster spec: mirrors: - sourceConnector: autoRestart: enabled: true # ... heartbeatConnector: autoRestart: enabled: true # ... checkpointConnector: autoRestart: enabled: true # ... 135.1. AutoRestart schema properties Property Property type Description enabled boolean Whether automatic restart for failed connectors and tasks should be enabled or disabled. maxRestarts integer The maximum number of connector restarts that the operator will try. If the connector remains in a failed state after reaching this limit, it must be restarted manually by the user. Defaults to an unlimited number of restarts.

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true maxRestarts: 10
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mm2-cluster spec: mirrors: - sourceConnector: autoRestart: enabled: true # heartbeatConnector: autoRestart: enabled: true # checkpointConnector: autoRestart: enabled: true #
Chapter 2. Multicluster storage health To view the overall storage health status across all the clusters with OpenShift Data Foundation and manage its capacity, you must first enable the multicluster dashboard on the Hub cluster. 2.1. Enabling multicluster dashboard on Hub cluster You can enable the multicluster dashboard on the install screen either before or after installing ODF Multicluster Orchestrator with the console plugin. Prerequisites Ensure that you have installed OpenShift Container Platform version 4.14 and have administrator privileges. Ensure that you have installed Multicluster Orchestrator 4.14 operator with plugin for console enabled. Ensure that you have installed Red Hat Advanced Cluster Management for Kubernetes (RHACM) 2.9 from Operator Hub. For instructions on how to install, see Installing RHACM . Ensure you have enabled observability on RHACM. See Enabling observability guidelines . Procedure Create the configmap file named observability-metrics-custom-allowlist.yaml and add the name of the custom metric to the metrics_list.yaml parameter. You can use the following YAML to list the OpenShift Data Foundation metrics on Hub cluster. For details, see Adding custom metrics . Run the following command in the open-cluster-management-observability namespace: After observability-metrics-custom-allowlist yaml is created, RHACM will start collecting the listed OpenShift Data Foundation metrics from all the managed clusters. If you want to exclude specific managed clusters from collecting the observability data, add the following cluster label to your clusters: observability: disabled . To view the multicluster health, see chapter verifying multicluster storage dashboard . 2.2. Verifying multicluster storage health on hub cluster Prerequisites Ensure that you have enabled multicluster monitoring. For instructions, see chapter Enabling multicluster dashboard . Procedure In the OpenShift web console of Hub cluster, ensure All Clusters is selected. Navigate to Data Services and click Storage System . On the Overview tab, verify that there are green ticks in front of OpenShift Data Foundation and Systems . This indicates that the operator is running and all storage systems are available. In the Status card, Click OpenShift Data Foundation to view the operator status. Click Systems to view the storage system status. The Storage system capacity card shows the following details: Name of the storage system Cluster name Graphical representation of total and used capacity in percentage Actual values for total and used capacity in TiB

Commands:
kind: ConfigMap apiVersion: v1 metadata: name: observability-metrics-custom-allowlist Namespace: open-cluster-management-observability data: metrics_list.yaml: | names: - odf_system_health_status - odf_system_map - odf_system_raw_capacity_total_bytes - odf_system_raw_capacity_used_bytes matches: - __name__="csv_succeeded",exported_namespace="openshift-storage",name=~"odf-operator.*"
oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
1.2. Application Compatibility This release of Red Hat Enterprise Linux provides dependencies so applications designed to run on earlier versions of the operating system continue to run with minimum disruption. To that end, older versions of key libraries are included to preserve legacy interfaces that might have changed between this release and prior versions. These libraries serve as dependencies primarily for applications written in C/C++. Note that it is not necessary to re-test or re-certify applications between minor releases of Red Hat Enterprise Linux. Red Hat Enterprise Linux compatibility policies ensure that applications running on a version of the release will continue to run throughout the life of the release. For example, applications certified on Red Hat Enterprise Linux 6.0 will be fully compatible on Red Hat Enterprise Linux 6.1 and so on. Refer to the following table for details on these compatibility packages: Table 1.1. Compatibility Libraries Package Description compat-db The Berkeley DB database compatibility library. The Berkeley Database (Berkeley DB) is a programmatic toolkit that provides embedded database support for both traditional and client-server applications. This package contains various versions of Berkeley DB which were included in releases. compat-expat1 Expat is a stream-oriented XML parser. This package provides library compatibility with versions. compat-glibc glibc is the C library used for system calls and other basic facilities. This package provides compatibility (and runtime libraries) for the compiling of binaries that require older glibc versions, and allows them to run on this release of Red Hat Enterprise Linux. compat-libf2c-34 This package provides older versions of Fortran 77 shared libraries, which are needed to run dynamically-linked Fortran 77 programs. compat-libgcc-296 Contains the 2.96 libgcc.a library and support object files to retain compatibility with older versions of GCC. compat-libgfortran-41 This package includes a Fortran 95 runtime library for compatibility with GCC 4.1.x compiled Fortran applications. compat-libstdc++-295 Provides compatibility with the GNU standard C++ library version 2.95. compat-libstdc++-296 Provides compatibility with the GNU standard C++ library version 2.96. compat-libstdc++-33 Provides compatibility with the GNU standard C++ library version 3.3. compat-libtermcap This package provides compatibility for older termcap-based programs. compat-openldap OpenLDAP is an open source suite of LDAP (Lightweight Directory Access Protocol) applications and development tools. The compat-openldap package includes older versions of the OpenLDAP shared libraries which are sometimes required by some applications. openssl098e This package provides OpenSSL 0.98e, which is required for some SSL applications.

Commands:
Chapter 1. Long Term Support for AMQ Interconnect 1.10 AMQ Interconnect 1.10 has been designated as a Long Term Support (LTS) release version. Bug fixes and security advisories will be made available for AMQ Interconnect 1.10 in a series of micro releases (1.10.1, 1.10.2, 1.10.3, and so on) for a period of at least 12 months. This means that you will be able to get recent bug fixes and security advisories for AMQ Interconnect without having to upgrade to a new minor release. Note the following important points about the LTS release stream: The LTS release stream provides only bug fixes. No new enhancements will be added to this stream. To remain in a supported configuration, you must upgrade to the latest micro release in the LTS release stream. The LTS version will be supported for at least 12 months from the time of the AMQ Interconnect 1.10.0 GA. Note AMQ Interconnect 2 will not support OpenShift Container Platform 3.11. To continue using OpenShift Container Platform 3.11, Red Hat recommends using this LTS release.

Commands:
5.336. tsclient 5.336.1. RHBA-2012:0382 - tsclient bug fix update An updated tsclient package that fixes one bug is now available for Red Hat Enterprise Linux 6. The tsclient utility is a GTK2 front end that makes it easy to use the Remote Desktop Protocol client (rdesktop) and vncviewer utilities. Bug Fix BZ# 734826 When opening an X Display Manager Control Protocol (XDMCP) connection using the tsclient utility, tsclient could terminate unexpectedly with a segmentation fault. A patch has been applied to address this issue, so that an XDMCP connection is now started correctly for the configured host. All users of tsclient are advised to upgrade to this updated package, which fixes this bug.

Commands:
10.3. After Installation After installing the httpd package, review the Apache HTTP Server's documentation available online at http://httpd.apache.org/docs-2.0/ . The Apache HTTP Server's documentation contains a full list and complete descriptions of all configuration options. This chapter provides short descriptions of the configuration directives used by Apache HTTP Server 2.0. The Apache HTTP Server 2.0 includes the ability to set up secure Web servers using the strong SSL encryption provided by the mod_ssl and openssl packages. When looking through the configuration files, be aware that it includes both a non-secure and a secure Web server. The secure Web server runs as a virtual host, which is configured in the /etc/httpd/conf.d/ssl.conf file. For more information about virtual hosts, refer to Section 10.8, "Virtual Hosts" . For information on configuring a secure server virtual host, refer to Section 10.8.1, "Setting Up Virtual Hosts" . For information on setting up an Apache HTTP Secure Server, refer to the chapter titled Apache HTTP Secure Server Configuration in the System Administrators Guide . Note Red Hat, Inc does not ship FrontPage extensions as the Microsoft TM license prohibits the inclusion of these extensions in a third party product. More information about FrontPage extensions and the Apache HTTP Server can be found online at http://www.rtr.com/fpsupport/ .

Commands:
Chapter 5. Listing files in your bucket To list files in a specific bucket, use the list_bucket_v2() method. Prerequisites You have cloned the odh-doc-examples repository to your workbench. You have opened the s3client_examples.ipynb file in your workbench. You have installed Boto3 and configured an S3 client. Procedure In the notebook, locate the following code for listing files. Replace <bucket_name> with the name of your own bucket, as shown in the example, and then run the code cell. The output displays information about the files that are available in the specified bucket. Locate the code cell that lists only the names of the files. Replace <bucket_name> with the name of your bucket, as shown in the example, and run the code cell: The output displays a list of file names that are available in the specified bucket. Refine the query to specify a file path, by locating the following code cell: Replace <bucket_name> and <start_of_file_path> with your own values and run the code cell.

Commands:
#List files #Replace <bucket_name> with the name of the bucket. bucket_name = '<bucket_name>' s3_client.list_objects_v2(Bucket=bucket_name)
#List files #Replace <bucket_name> with the name of the bucket. bucket_name = 'aqs27-registry' s3_client.list_objects_v2(Bucket=bucket_name)
#Print only names of files bucket_name = '<bucket_name>' for key in s3_client.list_objects_v2(Bucket=bucket_name)['Contents']: print(key['Key'])
#Print only names of files bucket_name = 'aqs27-registry' for key in s3_client.list_objects_v2(Bucket=bucket_name)['Contents']: print(key['Key'])
bucket_name = '<bucket_name>' for key in s3_client.list_objects_v2(Bucket=bucket_name,Prefix='<start_of_file_path')['Contents']: print(key['Key'])
4.2. Testing the Key Archival and Recovery Setup Note Newer browsers do not support key archival from the browser; for Step 1, one should substitute CRMF generation clients for those browsers. To test whether a key can be successfully archived: Enroll for dual certificates using the CA's Manual User Signing & Encryption Certificates Enrollment form. Submit the request. Log in to the agent services page, and approve the request. Log into the end-entities page, and check to see if the certificates have been issued. In the list of certificates, there should be two new certificates with consecutive serial numbers. Import the certificates into the web browser. Confirm that the key has been archived. In the KRA's agent services page, select Show completed requests . If the key has been archived successfully, there will be information about that key. If the key is not shown, check the logs, and correct the problem. If the key has been successfully archived, close the browser window. Verify the key. Send a signed and encrypted email. When the email is received, open it, and check the message to see if it is signed and encrypted. There should be a security icon at the top-right corner of the message window that indicates that the message is signed and encrypted. Delete the certificate. Check the encrypted email again; the mail client should not be able to decrypt the message. Test whether an archived key can be recovered successfully: Open the KRA's agent services page, and click the Recover Keys link. Search for the key by the key owner, serial number, or public key. If the key has been archived successfully, the key information will be shown. Click Recover . In the form that appears, enter the base-64 encoded certificate that corresponds to the private key to recover; use the CA to get this information. If the archived key was searched for by providing the base-64 encoded certificate, then the certificate does not have to be supplied here. Make sure that the Async Recovery checkbox is selected to allow the browser session to be closed while recovery is ongoing. Note An async recovery is the default and recommended way to perform a key recovery. If you want to perform a synchronous key recovery, the browser window cannot be shut and the KRA cannot be stopped during the recovery process. Depending on the agent scheme, a specified number of agents must authorize this key recovery. Have the agents search for the key to recover and then to approve the initiated recovery. Once all the agents have authorized the recovery, the screen requests a password to encrypt the PKCS #12 file with the certificate. The screen returns a link to download a PKCS #12 blob containing the recovered key pair. Follow the link, and save the blob to file. Important Opening the PKCS #12 file directly from the browser in the gcr-viewer utility can fail in certain situations. To work around the problem, download the file and manually open it in gcr-viewer . Restore the key to the browser's database. Import the .p12 file into the browser and mail client. Open the test email. The message should be shown again.

Commands:
Chapter 8. Custom Login Modules In cases where the login modules bundled with the JBoss EAP security framework do not meet the needs of the security environment, a custom login module implementation may be written. The org.jboss.security.AuthenticationManager requires a particular usage pattern of the Subject principals set. A full understanding of the JAAS Subject class's information storage features and the expected usage of these features are required to write a login module that works with the org.jboss.security.AuthenticationManager . Custom login modules must be implementations of javax.security.auth.spi.LoginModule . Refer to the API documentation for more information about creating a custom authentication module.

Commands:
Chapter 13. Enabling the Red Hat OpenShift Data Foundation console plugin The Data Foundation console plugin is enabled by default. In case, this option was unchecked during OpenShift Data Foundation Operator installation, use the following instructions to enable the console plugin post-deployment either from the graphical user interface (GUI) or command-line interface. Prerequisites You have administrative access to the OpenShift Web Console. OpenShift Data Foundation Operator is installed and running in the openshift-storage namespace. Procedure From user interface In the OpenShift Web Console, click Operators Installed Operators to view all the installed operators. Ensure that the Project selected is openshift-storage . Click on the OpenShift Data Foundation operator. Enable the console plugin option. In the Details tab, click the pencil icon under Console plugin . Select Enable , and click Save . From command-line interface Execute the following command to enable the console plugin option: Verification steps After the console plugin option is enabled, a pop-up with a message, Web console update is available appears on the GUI. Click Refresh web console from this pop-up for the console changes to reflect. In the Web Console, navigate to Storage and verify if Data Foundation is available.

Commands:
oc patch console.operator cluster -n openshift-storage --type json -p '[{"op": "add", "path": "/spec/plugins", "value": ["odf-console"]}]'