mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. 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. 9.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. 9.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", } }
4.139. libica 4.139.1. RHBA-2011:1567 - libica bug fix and enhancement update Updated libica packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libica library contains a set of functions and utilities for accessing the IBM eServer Cryptographic Accelerator (ICA) hardware on the IBM System z. The libica library has been upgraded to version 2.1, which provides a number of bug fixes and enhancements over the version. (BZ# 694247 ) All libica users are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Part IV. Interacting with Red Hat Process Automation Manager using KIE APIs As a business rules developer or system administrator, you can use KIE APIs to interact with KIE Servers, KIE containers, and business assets in Red Hat Process Automation Manager. You can use the KIE Server REST API and Java client API to interact with KIE containers and business assets (such as business rules, processes, and solvers), the Process Automation Manager controller REST API and Java client API to interact with KIE Server templates and instances, and the Knowledge Store REST API to interact with spaces and projects in Business Central. REST API endpoints for KIE Server and the Process Automation Manager controller The lists of REST API endpoints for KIE Server and the Process Automation Manager controller are published separately from this document and maintained dynamically to ensure that endpoint options and data are as current as possible. Use this document to understand what the KIE Server and Process Automation Manager controller REST APIs enable you to do and how to use them, and use the separately maintained lists of REST API endpoints for specific endpoint details. For the full list of KIE Server REST API endpoints and descriptions, use one of the following resources: Execution Server REST API on the jBPM Documentation page (static) Swagger UI for the KIE Server REST API at http://SERVER:PORT/kie-server/docs (dynamic, requires running KIE Server) For the full list of Process Automation Manager controller REST API endpoints and descriptions, use one of the following resources: Controller REST API on the jBPM Documentation page (static) Swagger UI for the Process Automation Manager controller REST API at http://SERVER:PORT/CONTROLLER/docs (dynamic, requires running Process Automation Manager controller) Prerequisites Red Hat Process Automation Manager is installed and running. For installation and startup options, see Planning a Red Hat Process Automation Manager installation . You have access to Red Hat Process Automation Manager with the following user roles: kie-server : For access to KIE Server API capabilities, and access to headless Process Automation Manager controller API capabilities without Business Central (if applicable) rest-all : For access to Business Central API capabilities for the built-in Process Automation Manager controller and for the Business Central Knowledge Store admin : For full administrative access to Red Hat Process Automation Manager Although these user roles are not all required for every KIE API, consider acquiring all of them to ensure that you can access any KIE API without disruption. For more information about user roles, see Planning a Red Hat Process Automation Manager installation .

Commands:
6.3.2. Moving the Data You can move all the used physical extents in /dev/sdc1 to /dev/sdb1 with the pvmove command. The pvmove command can take a long time to execute. After moving the data, you can see that all of the space on /dev/sdc1 is free.

Commands:
pvmove /dev/sdc1 /dev/sdb1 /dev/sdc1: Moved: 14.7% /dev/sdc1: Moved: 30.3% /dev/sdc1: Moved: 45.7% /dev/sdc1: Moved: 61.0% /dev/sdc1: Moved: 76.6% /dev/sdc1: Moved: 92.2% /dev/sdc1: Moved: 100.0%
pvscan PV /dev/sda1 VG myvg lvm2 [17.15 GB / 0 free] PV /dev/sdb1 VG myvg lvm2 [17.15 GB / 10.80 GB free] PV /dev/sdc1 VG myvg lvm2 [17.15 GB / 17.15 GB free] Total: 3 [51.45 GB] / in use: 3 [51.45 GB] / in no VG: 0 [0 ]
Chapter 26. Probe schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaExporterSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , TlsSidecar , ZookeeperClusterSpec Property Property type Description initialDelaySeconds integer The initial delay before first the health is first checked. Default to 15 seconds. Minimum value is 0. timeoutSeconds integer The timeout for each attempted health check. Default to 5 seconds. Minimum value is 1. periodSeconds integer How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. successThreshold integer Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1. failureThreshold integer Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1.

Commands:
25.3. Transaction Recovery The Transaction Manager coordinates the recovery process and works with Red Hat JBoss Data Grid to determine which transactions require manual intervention to complete operations. This process is known as transaction recovery. JBoss Data Grid uses JMX for operations that explicitly force transactions to commit or roll back. These methods receive byte arrays that describe the XID instead of the number associated with the relevant transactions. The System Administrator can use such JMX operations to facilitate automatic job completion for transactions that require manual intervention. This process uses the Transaction Manager's transaction recovery process and has access to the Transaction Manager's XID objects. Report a bug 25.3.1. Transaction Recovery Process The following process outlines the transaction recovery process in Red Hat JBoss Data Grid. Procedure 25.3. The Transaction Recovery Process The Transaction Manager creates a list of transactions that require intervention. The system administrator, connected to JBoss Data Grid using JMX, is presented with the list of transactions (including transaction IDs) using email or logs. The status of each transaction is either COMMITTED or PREPARED . If some transactions are in both COMMITTED and PREPARED states, it indicates that the transaction was committed on some nodes while in the preparation state on others. The System Administrator visually maps the XID received from the Transaction Manager to a JBoss Data Grid internal ID. This step is necessary because the XID (a byte array) cannot be conveniently passed to the JMX tool and then reassembled by JBoss Data Grid without this mapping. The system administrator forces the commit or rollback process for a transaction based on the mapped internal ID. Report a bug 25.3.2. Transaction Recovery Example The following example describes how transactions are used in a situation where money is transferred from an account stored in a database to an account stored in Red Hat JBoss Data Grid. Example 25.2. Money Transfer from an Account Stored in a Database to an Account in JBoss Data Grid The TransactionManager.commit() method is invoked to run the two phase commit protocol between the source (the database) and the destination (JBoss Data Grid) resources. The TransactionManager tells the database and JBoss Data Grid to initiate the prepare phase (the first phase of a Two Phase Commit). During the commit phase, the database applies the changes but JBoss Data Grid fails before receiving the Transaction Manager's commit request. As a result, the system is in an inconsistent state due to an incomplete transaction. Specifically, the amount to be transferred has been subtracted from the database but is not yet visible in JBoss Data Grid because the prepared changes could not be applied. Transaction recovery is used here to reconcile the inconsistency between the database and JBoss Data Grid entries. Note To use JMX to manage transaction recoveries, JMX support must be explicitly enabled. Report a bug

Commands:
Chapter 1. Schedule and quota APIs 1.1. AppliedClusterResourceQuota [quota.openshift.io/v1] Description AppliedClusterResourceQuota mirrors ClusterResourceQuota at a project scope, for projection into a project. It allows a project-admin to know which ClusterResourceQuotas are applied to his project and their associated usage. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.2. ClusterResourceQuota [quota.openshift.io/v1] Description ClusterResourceQuota mirrors ResourceQuota at a cluster scope. This object is easily convertible to synthetic ResourceQuota object to allow quota evaluation re-use. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.3. FlowSchema [flowcontrol.apiserver.k8s.io/v1beta3] Description FlowSchema defines the schema of a group of flows. Note that a flow is made up of a set of inbound API requests with similar attributes and is identified by a pair of strings: the name of the FlowSchema and a "flow distinguisher". Type object 1.4. LimitRange [v1] Description LimitRange sets resource usage limits for each kind of resource in a Namespace. Type object 1.5. PriorityClass [scheduling.k8s.io/v1] Description PriorityClass defines mapping from a priority class name to the priority integer value. The value can be any valid integer. Type object 1.6. PriorityLevelConfiguration [flowcontrol.apiserver.k8s.io/v1beta3] Description PriorityLevelConfiguration represents the configuration of a priority level. Type object 1.7. ResourceQuota [v1] Description ResourceQuota sets aggregate quota restrictions enforced per namespace Type object

Commands:
Chapter 17. The Cluster App Quickstart The EAP Cluster App quickstart demonstrates how to use a JBoss Data Grid cache in library mode. There are three different applications which show: How to create and use a JBoss Data Grid clustered cache without having a JBoss EAP cluster. A configuration where the JBoss EAP cluster is independent of an Infinispan cluster. One JBoss EAP instance can use JBoss Data Grid caches which are members of a different JBoss Data Grid cluster. Programming cache configuration using the JBoss Data Grid API. File based configuration, seen in administration application App1Cache. Use CDI to inject the cache managers. Each application contains an embedded JBoss Data Grid cache which is accessed by stateless EJB's in the same application. Different JBoss EAP servers, with the exception of AppTwo, are not clustered to demonstrate that an unclustered application can share the JBoss Data Grid cache. In addition, there are two cache managers, neither of which are members of the same JBoss Data Grid cluster. The AdminApp accesses and modified both of these caches. AppOne can only read the App1Cache, but it uses a clustered EJB invocation to AppTwo to read from App2Cache; while AppTwo is deployed as a clustered EJB application and only read App2Cache. Report a bug 17.1. EAP Cluster App Prerequisites The prerequisites for the EAP Cluster App are as follows: Java 6.0 (Java SDK 1.6) or better JBoss Enterprise Application Platform 6.1 or later Maven 3.0 or better Configure the Maven repository. For details, see Chapter 3, Install and Use the Maven Repositories . JBoss Data Grid modules installed in the JBoss EAP server. Report a bug

Commands:
Chapter 1. Support policy for Red Hat build of OpenJDK Red Hat will support select major versions of Red Hat build of OpenJDK in its products. For consistency, these versions remain similar to Oracle JDK versions that are designated as long-term support (LTS). A major version of Red Hat build of OpenJDK will be supported for a minimum of six years from the time that version is first introduced. For more information, see the OpenJDK Life Cycle and Support Policy . Note RHEL 6 reached the end of life in November 2020. Because of this, Red Hat build of OpenJDK is not supporting RHEL 6 as a supported configuration..

Commands:
Preface Red Hat Fuse Tooling is an Eclipse-based IDE that simplifies and streamlines the process of developing integration applications within Red Hat CodeReady Studio. Fuse Tooling provides a set of developer tools that are specifically designed to work with: Red Hat Fuse Red Hat JBoss EAP Apache Camel Apache CXF Apache Karaf Spring Boot This guide provides information about how to use Fuse Tooling to: Create a project for your application, including Maven dependencies Connect and configure Enterprise Integration Patterns to build routes Browse endpoints and routes Drag and drop messages onto running routes Browse and visualize runtime processes via JMX Debug locally running Camel contexts and routes Test your application by: Creating and using JUnit test cases on Apache Camel routes Using JMX to analyze running components Tracing messages through Apache Camel routes Deploy your application For new users, the Tooling Tutorials provide step-by-step instructions on how to create, debug, test, and deploy a sample Camel application.

Commands:
7.172. parted 7.172.1. RHBA-2013:0407 - parted bug fix and enhancement update Updated parted packages that fix three bugs are now available for Red Hat Enterprise Linux 6. The parted packages provide a disk partitioning and partition resizing program to create, destroy, resize, move and copy ext2, linux-swap, FAT, FAT32, and reiserfs partitions. Bug Fixes BZ# 797979 Prior to this update, the parted program did not handle unexpected values in the HFS+ filesystem correctly. As a consequence, parted aborted with a segmentation fault. This update adds additional checks for unexpected values to the HFS+ code. Now, parted no longer aborts when handling unexpected values. BZ# 803108 Prior to this update, the parted program re-synchronized only the first 16 partitions on dm devices. As a consequence, all partitions after the 16th only appeared after reboot. This update modifies the underlying code to resynchronize all of the partitions. Now, new partitions also appear without a reboot. All parted users are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 3. Build strategies You can use a curated set of build strategies or cluster build strategies on the OpenShift Container Platform cluster. The Builds for Red Hat OpenShift Operator automatically installs these strategies for use. This automated installation of strategies helps you to quickly get started with Builds. Builds supports the following cluster build strategies: buildah : Supported on all platforms source-to-image : Supported on the linux/amd64 platform Note The buildpacks build strategy is currently in Developer Preview . For more information, see the buildpacks example . 3.1. Buildah The buildah cluster build strategy uses a Dockerfile to build a container image and pushes it to the target registry. You must specify the Dockerfile in the spec.paramValues field of the Build CR. You can share the buildah strategy across different namespaces within your cluster because the Builds for Red Hat OpenShift Operator installs the buildah strategy at cluster level. You can configure the following parameters for the buildah strategy: Table 3.1. Configuration parameters for buildah Name Type Description Default build-args array Key-value pair of the arguments required by the Dockerfile that is used during the build [] registries-block array List of registries that must be blocked [] registries-insecure array List of insecure registries with their fully qualified domain name (FQDN) [] registries-search array List of registries to search short name images ["registry.redhat.io", "quay.io"] dockerfile string Path of the Dockerfile that is used during the build "Dockerfile" storage-driver string Storage drivers that are used by buildah , such as overlay or vfs "vfs" Note For more information, see Configuring build strategies in the Additional resources section. 3.2. Source-to-image This build strategy is composed of source-to-image and buildah . You can use this strategy to generate a container file and prepare the application to build with a builder image. You must specify the builder image in the spec.paramValues field of the Build CR. You can share the source-to-image strategy across different namespaces within your cluster because the Builds for Red Hat OpenShift Operator installs the source-to-image strategy at cluster level. You can configure the following parameters for the source-to-image strategy: Table 3.2. Configuration parameters for source-to-image Name Type Description Default registries-block array List of registries that must be blocked [] registries-insecure array List of insecure registries with their FQDN [] registries-search array List of registries to search short name images ["registry.redhat.io", "quay.io"] builder-image string Location of the builder image that is used during the build NA storage-driver string Storage drivers that are used by source-to-image , such as overlay or vfs "vfs" 3.3. Additional resources Installing Builds by using the web console Installing Builds by using the CLI Configuring build strategies Creating a ShipwrightBuild resource by using the web console

Commands:
Chapter 8. Message delivery 8.1. Sending messages To send a message, create a client, connection and a sender Example: Sending messages IConnection connection = client.Connect(serverHost, serverPort, options); SenderOptions senderOptions = new SenderOptions(); ISender sender = connection.OpenSender(address, senderOptions); IMessage<string> message = IMessage<string>.Create("Hello World!")); ITracker tracker = sender.Send(message); For more information, see the Send example . 8.2. Tracking sent messages When the message is sent a Tracker is returned which can be used to track the message or settle it if not using auto settlement Example: waiting for the broker to settle the message tracker.AwaitSettlement(); Example: settling the messsage tracker.Settle(); 8.3. Receiving messages To receive a message, create a connection, client and receiver. Example: Receiving messages IConnection connection = client.Connect(serverHost, serverPort, options); using IReceiver receiver = connection.OpenReceiver(address); IDelivery delivery = receiver.Receive(); IMessage<object> received = delivery.Message(); The Receiver.Accept() call tells the remote peer that the message was received and processed. For more information, see the Receive example . 8.4. Acknowledging received messages The IDelivery object can be used to accept, reject modify the delivery. Example: Acknowledging received messages ---- delivery.Accept() ---- Example: Rejecting received messages ---- delivery.Reject() ---- Example: Releasing received messages ---- delivery.Release() ----

Commands:
IConnection connection = client.Connect(serverHost, serverPort, options); SenderOptions senderOptions = new SenderOptions(); ISender sender = connection.OpenSender(address, senderOptions); IMessage<string> message = IMessage<string>.Create("Hello World!")); ITracker tracker = sender.Send(message);
tracker.AwaitSettlement();
tracker.Settle();
IConnection connection = client.Connect(serverHost, serverPort, options); using IReceiver receiver = connection.OpenReceiver(address); IDelivery delivery = receiver.Receive(); IMessage<object> received = delivery.Message();
---- delivery.Accept() ----
---- delivery.Reject() ----
---- delivery.Release() ----
About Builds builds for Red Hat OpenShift 1.3 Introduction to Builds Red Hat OpenShift Documentation Team

Commands:
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build spec: source: git: url: https://github.com/username/taxi strategy: name: buildah kind: ClusterBuildStrategy output: image: registry.mycompany.com/my-org/taxi-app:latest
apiVersion: shipwright.io/v1beta1 kind: ClusterBuildStrategy metadata: name: buildah spec: steps: - name: build-and-push image: quay.io/containers/buildah:v1.31.0 workingDir: USD(params.shp-source-root) command: - /bin/bash #
1.2. A Three-Tier LVS Configuration Figure 1.2, "A Three-Tier LVS Configuration" shows a typical three-tier LVS topology. In this example, the active LVS router routes the requests from the Internet to the pool of real servers. Each of the real servers then accesses a shared data source over the network. Figure 1.2. A Three-Tier LVS Configuration This configuration is ideal for busy FTP servers, where accessible data is stored on a central, highly available server and accessed by each real server via an exported NFS directory or Samba share. This topology is also recommended for websites that access a central, highly available database for transactions. Additionally, using an active-active configuration with Red Hat Cluster Manager, administrators can configure one high-availability cluster to serve both of these roles simultaneously. The third tier in the above example does not have to use Red Hat Cluster Manager, but failing to use a highly available solution would introduce a critical single point of failure.

Commands: