mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 106. Verifying system certificates using IdM Healthcheck Learn more about identifying issues with system certificates in Identity Management (IdM) by using the Healthcheck tool. For details, see Healthcheck in IdM . Prerequisites The Healthcheck tool is only available on RHEL 8.1 or newer. 106.1. System certificates Healthcheck tests The Healthcheck tool includes several tests for verifying system (DogTag) certificates. To see all tests, run the ipa-healthcheck with the --list-sources option: You can find all tests under the ipahealthcheck.dogtag.ca source: DogtagCertsConfigCheck This test compares the CA (Certificate Authority) certificates in its NSS database to the same values stored in CS.cfg . If they do not match, the CA fails to start. Specifically, it checks: auditSigningCert cert-pki-ca against ca.audit_signing.cert ocspSigningCert cert-pki-ca against ca.ocsp_signing.cert caSigningCert cert-pki-ca against ca.signing.cert subsystemCert cert-pki-ca against ca.subsystem.cert Server-Cert cert-pki-ca against ca.sslserver.cert If Key Recovery Authority (KRA) is installed: transportCert cert-pki-kra against ca.connector.KRA.transportCert DogtagCertsConnectivityCheck This test verifies connectivity. This test is equivalent to the ipa cert-show 1 command which checks: The PKI proxy configuration in Apache IdM being able to find a CA The RA agent client certificate Correctness of CA replies to requests Note that the test checks a certificate with serial #1 because you want to verify that a cert-show can be executed and get back an expected result from CA (either the certificate or a not found). Note Run these tests on all IdM servers when trying to find an issue. 106.2. Screening system certificates using Healthcheck Follow this procedure to run a standalone manual test of Identity Management (IdM) certificates using the Healthcheck tool. Since, the Healthcheck tool includes many tests, you can narrow the results by including only DogTag tests: --source=ipahealthcheck.dogtag.ca Procedure To run Healthcheck restricted to DogTag certificates, enter: An example of a successful test: An example of a failed test: Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.dogtag.ca
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: SUCCESS", "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c", "when: 20191008135826Z", "duration: 0.252280", "kw:" { "key": "Server-Cert cert-pki-ca", "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg" } }
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: CRITICAL", "uuid: 59d66200-1447-4b3b-be01-89810c803a98", "when: 20191008135912Z", "duration: 0.002022", "kw:" { "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized", } }
2.5. Fibre Channel Storage Devices Table 2.3, "Fibre Channel Storage Device Requirements" shows requirements for Fibre Channel devices that are to be connected to a GFS cluster. Table 2.3. Fibre Channel Storage Device Requirements Requirement Description Device Type FC RAID array or JBOD Note: Make sure that the devices can operate reliably when heavily accessed simultaneously from multiple initiators. Note: Make sure that your GFS configuration does not exceed the number of nodes an array or JBOD supports. Size GFS is based on a 64-bit architecture, which can theoretically accommodate an 8 EB file system. However, the current supported maximum size of a GFS file system is 25 TB. If your system requires GFS file systems larger than 25 TB, contact your Red Hat service representative. When determining the size of your file system, you should consider your recovery needs. Running the fsck command on the file system can take a long time and consume a large amount of memory. Additionally, in the event of a disk or disk-subsytem failure, recovery time is limited by the speed of your backup media.

Commands:
Appendix A. Directory Server RFC Support Note This chapter lists notable supported LDAP-related RFCs. It is not a complete list of RFCs Directory Server supports. A.1. LDAPv3 Features Technical Specification Road Map ( RFC 4510 ) This is a tracking document and does not contain requirements. The Protocol ( RFC 4511 ) Supported. Exceptions: RFC 4511 Section 4.4.1. Notice of Disconnection : Directory Server terminates the connections in this case. RFC 4511 Section 4.5.1.3. SearchRequest.derefAliases : LDAP aliases are not supported. RFC 4511 Section 4.13. IntermediateResponse Message Directory Information Models ( RFC 4512 ) Supported. Exceptions: RFC 4512 Section 2.4.2. Structural Object Classes : Directory Server supports entries with multiple structural object classes. RFC 4512 Section 2.6. Alias Entries RFC 4512 Section 4.1.2. Attribute Types : The attribute type COLLECTIVE is not supported. RFC 4512 Section 4.1.4. Matching Rule Uses RFC 4512 Section 4.1.6. DIT Content Rules RFC 4512 Section 4.1.7. DIT Structure Rules and Name Forms RFC 4512 Section 5.1.1. altServer Note that RFC 4512 enables LDAP servers to not support the previously listed exceptions. For further details, see RFC 4512 Section 7.1. Server Guidelines . Authentication Methods and Security Mechanisms ( RFC 4513 ) Supported. String Representation of Distinguished Names ( RFC 4514 ) Supported. String Representation of Search Filters ( RFC 4515 ) Supported. Uniform Resource Locator ( RFC 4516 ) Supported. However, this RFC is mainly focused on LDAP clients. Syntaxes and Matching Rules ( RFC 4517 ) Supported. Exceptions: directoryStringFirstComponentMatch integerFirstComponentMatch objectIdentifierFirstComponentMatch objectIdentifierFirstComponentMatch keywordMatch wordMatch Internationalized String Preparation ( RFC 4518 ) Supported. Schema for User Applications ( RFC 4519 ) Supported.

Commands:
Appendix B. Debug Perspective Use the Debug perspective to monitor and debug a running Camel context. Debug view For the running Camel context, the Debug view displays the debug stack. You can switch between breakpoints within the same message flow, listed under the Camel Context at service:jmx:rmi://jndi/rmi://localhost:1099/jmxrmi/camel entry, to review and compare variable values in the Variables view. Messages flows are identified by their unique breadcrumb ID, and the breadcrumb ID of each subsequent message flow is incremented by 2. For example, if the breadcrumb ID for the first message flow is ID-janemurpheysmbp-home-54620-1470949590275-0-1 , the breadcrumbID for the second message flow would be ID-janemurpheysmbp-home-54620-1470949590275-0-3 . Variables view For each node in the routing context that has a breakpoint set, the Variables view displays the value of the available variables when the breakpoint is hit. Each variable who's value changed since the preceding breakpoint is highlighted in yellow. You can change the value of editable variables to check whether such changes produce the expected results and to test the robustness of your routing context. You can also add variables to the watch list, so you can quickly and easily see whether their values change as expected at the expected point in the message flow. Breakpoints view Displays a list of the breakpoints set in the routing context, and shows whether they are enabled or disabled. You can enable and disable individual breakpoints by checking (enabling) or unchecking (disabling) them. This enables you to temporarily focus on nodes in your routing context that are behaving problematically. The button skips over disabled breakpoints to jump to the active breakpoint in the routing context. In contrast, the button jumps to the node of execution in the routing context, regardless of breakpoints. camel Context.xml view Displays the running routing context file in graphical mode. For nodes set with breakpoints, it shows the type of breakpoint set and whether the breakpoint is enabled or disabled. When a breakpoint is hit, its corresponding node on the canvas is outlined in red. To check a node's configuration, open the Properties view and then select the node on the canvas in camel Context.xml . Console view Displays the log output generated by the Camel debugger as it executes the routing context. Properties view Displays the properties set for the node selected on the canvas in CamelContext.xml .

Commands:
Chapter 1. Autoscale APIs 1.1. ClusterAutoscaler [autoscaling.openshift.io/v1] Description ClusterAutoscaler is the Schema for the clusterautoscalers API Type object 1.2. MachineAutoscaler [autoscaling.openshift.io/v1beta1] Description MachineAutoscaler is the Schema for the machineautoscalers API Type object 1.3. HorizontalPodAutoscaler [autoscaling/v2] Description HorizontalPodAutoscaler is the configuration for a horizontal pod autoscaler, which automatically manages the replica count of any resource implementing the scale subresource based on the metrics specified. Type object 1.4. Scale [autoscaling/v1] Description Scale represents a scaling request for a resource. Type object

Commands:
Chapter 11. Security, Standards and Certification Common Criteria Certification As of Red Hat Enterprise Linux 6.2 Beta, Red Hat Enterprise Linux 6 is under evaluation for Common Criteria certification at Evaluation Assurance Level (EAL) 4+. Common Criteria provides a standardized way of expressing security requirements and defines a set of rigorous criteria by which products are evaluated. FIPS-140 Validation As of Red Hat Enterprise Linux 6.2 Beta, Red Hat Enterprise Linux 6 cryptographic modules are under evaluation for FIPS-140 certification. FIPS-140 is a U.S. government security standard used for accrediting cryptographic modules. Red Hat Enterprise Linux now satisfies the regulatory requirement mandated by the U.S. federal government for acceptable use of cryptographic modules by all the governmental agencies. Trusted boot Red Hat Enterprise Linux 6.2 includes Intel Trusted Boot, a trusted boot mechanism (provided by the tboot package). Trusted boot is an install-time optional component that allows for Intel's Trusted Execution Technology (TXT) to perform a measured and verified launch of the operating system kernel. Trusted boot is supported on both Intel x86 and Intel 64 architectures.

Commands:
4.3. Additional Resources This chapter is only intended as an introduction to the files in the /etc/sysconfig/ directory. The following source contains more comprehensive information. 4.3.1. Installed Documentation /usr/share/doc/initscripts- <version-number> /sysconfig.txt - This file contains a more authoritative listing of the files found in the /etc/sysconfig/ directory and the configuration options available for them. The <version-number> in the path to this file corresponds to the version of the initscripts package installed.

Commands:
Chapter 1. Creating a manifest Create a manifest to import subscriptions to your subscription management application, such as Red Hat Satellite 6 or later. A new manifest is required whenever you create a new Satellite Server or Satellite organization. Prerequisites You are logged in to the Red Hat Hybrid Cloud Console. You are connected to a Red Hat Satellite Server. You have Red Hat Satellite 6 or later. You have the Subscriptions administrator role in the role-based access control (RBAC) system for the Red Hat Hybrid Cloud Console. If you do not have an active Satellite subscription and you have at least one existing subscription manifest for your account, then you can view and export your existing manifests, but the Create new manifest button is inactive until you reactivate your Satellite subscription. If you do not have an active Satellite subscription and you have no existing subscription manifests for your account, then you can click the Contact button to receive help from Red Hat. Procedure To create a subscription manifest, complete the following steps: From the Hybrid Cloud Console home page, click Services > Subscriptions and Spend > Manifests . From the Manifests page, click Create new manifest . In the Name field, enter a unique name for the manifest. From the Type list, select the application type and version number that corresponds to your Red Hat Satellite Server. Click Create . Additional resources For more information about using Satellite to manage your Red Hat subscriptions, see Managing Red Hat Subscriptions .

Commands:
1.2. haproxy HAProxy offers load balanced services to HTTP and TCP-based services, such as Internet-connected services and web-based applications. Depending on the load balancer scheduling algorithm chosen, haproxy is able to process several events on thousands of connections across a pool of multiple real servers acting as one virtual server. The scheduler determines the volume of connections and either assigns them equally in non-weighted schedules or given higher connection volume to servers that can handle higher capacity in weighted algorithms. HAProxy allows users to define several proxy services, and performs load balancing services of the traffic for the proxies. Proxies are made up of a frontend system and one or more back-end systems. The front-end system defines the IP address (the VIP) and port on which the proxy listens, as well as the back-end systems to use for a particular proxy. The back-end system is a pool of real servers, and defines the load balancing algorithm. HAProxy performs load-balancing management on layer 7, or the Application layer. In most cases, administrators deploy HAProxy for HTTP-based load balancing, such as production web applications, for which high availability infrastructure is a necessary part of business continuity.

Commands:
Chapter 1. Managing OpenShift Pipelines performance If your OpenShift Pipelines installation runs a large number of tasks at the same time, its performance might degrade. You might experience slowdowns and failed pipeline runs. For reference, in Red Hat tests, on a three-node OpenShift Container Platform cluster running on Amazon Web Services (AWS) m6a.2xlarge nodes, up to 60 simple test pipelines ran concurrently without significant failures or delays. If more pipelines ran concurrently, the number of failed pipeline runs, the average duration of a pipeline run, the pod creation latency, the work queue depth, and the number of pending pods increased. This testing was performed on Red Hat OpenShift Pipelines version 1.13; no statistically significant difference was observed from version 1.12. Note These results depend on the test configuration. Performance results with your configuration can be different. 1.1. Improving OpenShift Pipelines performance If you experience slowness or recurrent failures of pipeline runs, you can take any of the following steps to improve the performance of OpenShift Pipelines. Monitor the resource usage of the nodes in the OpenShift Container Platform cluster on which OpenShift Pipelines runs. If the resource usage is high, increase the number of nodes. Enable high-availability mode. This mode affects the controller that creates and starts pods for task runs and pipeline runs. In Red Hat testing, high-availability mode significantly reduced pipeline execution times as well as the delay from creating a TaskRun resource CR to the start of the pod executing the task run. To enable high-availability mode, make the following changes in the TektonConfig custom resource (CR): Set the pipeline.performance.disable-ha spec to false . Set the pipeline.performance.buckets spec to a number between 5 and 10 . Set the pipeline.performance.replicas spec to a number higher than 2 and lower than or equal to the pipeline.performance.buckets setting. Note You can try different numbers for buckets and replicas to observe the effect on performance. In general, higher numbers are beneficial. Monitor for exhausting the resources of the nodes, including CPU and memory utilization. 1.2. Additional resources Performance tuning using the TektonConfig CR

Commands:
Chapter 1. Overview of model registries Important Model registry is currently available in Red Hat OpenShift AI as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . A model registry is an important component in the lifecycle of an artificial intelligence/machine learning (AI/ML) model, and a vital part of any machine learning operations (MLOps) platform or ML workflow. A model registry acts as a central repository, holding metadata related to machine learning models from inception to deployment. This metadata ranges from high-level information like the deployment environment and project origins, to intricate details like training hyperparameters, performance metrics, and deployment events. A model registry acts as a bridge between model experimentation and serving, offering a secure, collaborative metadata store interface for stakeholders of the ML lifecycle. Model registries provide a structured and organized way to store, share, version, deploy, and track models. To use model registries in OpenShift AI, an OpenShift cluster administrator must configure the model registry component. For more information, see Configuring the model registry component . After the model registry component is configured, an OpenShift AI administrator can create model registries in OpenShift AI and grant model registry access to the data scientists that will work with them. For more information, see Managing model registries . Data scientists with access to a model registry can store, share, version, deploy, and track models using the model registry feature. For more information, see Working with model registries .

Commands:
Chapter 5. Changes in Rust 1.79.0 Toolset Rust Toolset has been updated from version 1.75.0 to 1.79.0 on RHEL 8 and RHEL 9. Notable changes include: A new offset_of! macro Support for C-string literals Support for inline const expressions Support for bounds in associated type position Improved automatic temporary lifetime extension Debug assertions for unsafe preconditions For detailed information regarding the updates, see the series of upstream release announcements: Announcing Rust 1.76.0 Announcing Rust 1.77.0 Announcing Rust 1.78.0 Announcing Rust 1.79.0

Commands:
probe::nfs.proc.commit_done Name probe::nfs.proc.commit_done - NFS client response to a commit RPC task Synopsis nfs.proc.commit_done Values status result of last operation server_ip IP address of server prot transfer protocol version NFS version count number of bytes committed valid fattr->valid, indicates which fields are valid timestamp V4 timestamp, which is used for lease renewal Description Fires when a reply to a commit RPC task is received or some commit operation error occur (timeout or socket shutdown).

Commands:
3.6. Tapsets Tapsets are scripts that form a library of pre-written probes and functions to be used in SystemTap scripts. When a user runs a SystemTap script, SystemTap checks the script's probe events and handlers against the tapset library; SystemTap then loads the corresponding probes and functions before translating the script to C (refer to Section 3.1, "Architecture" for information on what transpires in a SystemTap session). Like SystemTap scripts, tapsets use the file name extension .stp . The standard library of tapsets is located in /usr/share/systemtap/tapset/ by default. However, unlike SystemTap scripts, tapsets are not meant for direct execution; rather, they constitute the library from which other scripts can pull definitions. Simply put, the tapset library is an abstraction layer designed to make it easier for users to define events and functions. In a manner of speaking, tapsets provide useful aliases for functions that users may want to specify as an event; knowing the proper alias to use is, for the most part, easier than remembering specific kernel functions that might vary between kernel versions. Several handlers and functions in Section 3.2.1, "Event" and SystemTap Functions are defined in tapsets. For example, thread_indent() is defined in indent.stp .

Commands:
Chapter 11. Managing Red Hat Gluster Storage Volumes This chapter describes how to perform common volume management operations on the Red Hat Gluster Storage volumes. 11.1. Configuring Volume Options Note Volume options can be configured while the trusted storage pool is online. The current settings for a volume can be viewed using the following command: Volume options can be configured using the following command: For example, to specify the performance cache size for test-volume : Volume options can be reset using the following command: For example, to reset the changelog option for test-volume :

Commands:
gluster volume info VOLNAME
gluster volume set VOLNAME OPTION PARAMETER
gluster volume set test-volume performance.cache-size 256MB volume set: success
gluster volume reset VOLNAME OPTION_NAME
gluster volume reset test-volume changelog volume set: success
40.2. Configuring OProfile Before OProfile can be run, it must be configured. At a minimum, selecting to monitor the kernel (or selecting not to monitor the kernel) is required. The following sections describe how to use the opcontrol utility to configure OProfile. As the opcontrol commands are executed, the setup options are saved to the /root/.oprofile/daemonrc file. 40.2.1. Specifying the Kernel First, configure whether OProfile should monitor the kernel. This is the only configuration option that is required before starting OProfile. All others are optional. To monitor the kernel, execute the following command as root: Note The debuginfo package must be installed (which contains the uncompressed kernel) in order to monitor the kernel. To configure OProfile not to monitor the kernel, execute the following command as root: This command also loads the oprofile kernel module, if it is not already loaded, and creates the /dev/oprofile/ directory, if it does not already exist. Refer to Section 40.6, "Understanding /dev/oprofile/ " for details about this directory. Note Even if OProfile is configured not to profile the kernel, the SMP kernel still must be running so that the oprofile module can be loaded from it. Setting whether samples should be collected within the kernel only changes what data is collected, not how or where the collected data is stored. To generate different sample files for the kernel and application libraries, refer to Section 40.2.3, "Separating Kernel and User-space Profiles" .

Commands:
opcontrol --setup --vmlinux=/usr/lib/debug/lib/modules/`uname -r`/vmlinux
opcontrol --setup --no-vmlinux