mtpti5iD/redhat-docs_dataset huggingface dataset:
Part I. Packaging and deploying a Red Hat Decision Manager project As a business rules developer, you must build and deploy a developed Red Hat Decision Manager project to a KIE Server in order to begin using the services you have created in Red Hat Decision Manager. You can develop and deploy a project from Business Central, from an independent Maven project, from a Java application, or using a combination of various platforms. For example, you can develop a project in Business Central and deploy it using the KIE Server REST API, or develop a project in Maven configured with Business Central and deploy it using Business Central. Prerequisites The project to be deployed has been developed and tested. For projects in Business Central, consider using test scenarios to test the assets in your project. For example, see Testing a decision service using test scenarios .

Commands:
3.5.4. Processing Multiple Elements in an Array Once you have collected enough information in an array, you will need to retrieve and process all elements in that array to make it useful. Consider Example 3.14, "vfsreads.stp" : the script collects information about how many VFS reads each process performs, but does not specify what to do with it. The obvious means for making Example 3.14, "vfsreads.stp" useful is to print the key pairs in the array reads , but how? The best way to process all key pairs in an array (as an iteration) is to use the foreach statement. Consider the following example: Example 3.15. cumulative-vfsreads.stp In the second probe of Example 3.15, "cumulative-vfsreads.stp" , the foreach statement uses the variable count to reference each iteration of a unique key in the array reads . The reads[count] array statement in the same probe retrieves the associated value of each unique key. Given what we know about the first probe in Example 3.15, "cumulative-vfsreads.stp" , the script prints VFS-read statistics every 3 seconds, displaying names of processes that performed a VFS-read along with a corresponding VFS-read count. Now, remember that the foreach statement in Example 3.15, "cumulative-vfsreads.stp" prints all iterations of process names in the array, and in no particular order. You can instruct the script to process the iterations in a particular order by using + (ascending) or - (descending). In addition, you can also limit the number of iterations the script needs to process with the limit value option. For example, consider the following replacement probe: This foreach statement instructs the script to process the elements in the array reads in descending order (of associated value). The limit 10 option instructs the foreach to only process the first ten iterations (that is print the first 10, starting with the highest value).

Commands:
global reads probe vfs.read { reads[execname()] ++ } probe timer.s(3) { foreach (count in reads) printf("%s : %d \n", count, reads[count]) }
probe timer.s(3) { foreach (count in reads- limit 10) printf("%s : %d \n", count, reads[count]) }
Appendix A. Troubleshooting DNF modules If DNF modules fails to enable, it can mean an incorrect module is enabled. In that case, you have to resolve dependencies manually as follows. List the enabled modules: A.1. Ruby If Ruby module fails to enable, it can mean an incorrect module is enabled. In that case, you have to resolve dependencies manually as follows: List the enabled modules: If the Ruby 2.5 module has already been enabled, perform a module reset: A.2. PostgreSQL If PostgreSQL module fails to enable, it can mean an incorrect module is enabled. In that case, you have to resolve dependencies manually as follows: List the enabled modules: If the PostgreSQL 10 module has already been enabled, perform a module reset: If you created a PostgreSQL 10 database, perform an upgrade: Enable the DNF modules: Install the PostgreSQL upgrade package: Perform the upgrade:

Commands:
dnf module list --enabled
dnf module list --enabled
dnf module reset ruby
dnf module list --enabled
dnf module reset postgresql
dnf module enable satellite-capsule:el8
dnf install postgresql-upgrade
postgresql-setup --upgrade
Chapter 3. What is deployed with AMQ Streams Apache Kafka components are provided for deployment to OpenShift with the AMQ Streams distribution. The Kafka components are generally run as clusters for availability. A typical deployment incorporating Kafka components might include: Kafka cluster of broker nodes ZooKeeper cluster of replicated ZooKeeper instances Kafka Connect cluster for external data connections Kafka MirrorMaker cluster to mirror the Kafka cluster in a secondary cluster Kafka Exporter to extract additional Kafka metrics data for monitoring Kafka Bridge to make HTTP-based requests to the Kafka cluster Not all of these components are mandatory, though you need Kafka and ZooKeeper as a minimum. Some components can be deployed without Kafka, such as MirrorMaker or Kafka Connect. 3.1. Order of deployment The required order of deployment to an OpenShift cluster is as follows: Deploy the Cluster Operator to manage your Kafka cluster Deploy the Kafka cluster with the ZooKeeper cluster, and include the Topic Operator and User Operator in the deployment Optionally deploy: The Topic Operator and User Operator standalone if you did not deploy them with the Kafka cluster Kafka Connect Kafka MirrorMaker Kafka Bridge Components for the monitoring of metrics The Cluster Operator creates OpenShift resources for the components, such as Deployment , Service , and Pod resources. The names of the OpenShift resources are appended with the name specified for a component when it's deployed. For example, a Kafka cluster named my-kafka-cluster has a service named my-kafka-cluster-kafka .

Commands:
8.97. libtevent 8.97.1. RHBA-2013:1552 - libtevent bug fix and enhancement update Updated libtevent packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libtevent packages provide Tevent, an event system based on the talloc memory management library. Tevent supports many event types, including timers, signals, and the classic file descriptor events. Tevent also provides helpers to deal with asynchronous code represented by the tevent_req (Tevent Request) functions. Note The libtevent packages have been upgraded to upstream version 0.9.18, which provides a number of bug fixes and enhancements over the version. (BZ# 951034 ) Bug Fixes BZ# 975489 Prior to this update, a condition in the poll backend copied a 64-bit variable into an unsigned integer variable, which was smaller than 64-bit on 32-bit architectures. Using the unsigned integer variable in a condition rendered the condition to be always false. The variable format has been changed to the uint64_t format guaranteeing its width to be 64 bits on all architectures. As a result, the condition now yields expected results. BZ# 978962 Previously, the tevent_loop_wait() function internally registered its own signal handler even though it had been never removed. Consequently, tevent_loop_wait() could not end even there were no registered custom handlers. This update applies a patch to fix this bug and tevent_loop_wait() now works as expected. Users of libtevent are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
5.362. xorg-x11-drv-ati and mesa 5.362.1. RHEA-2012:0903 - xorg-x11-drv-ati and mesa bug fix and enhancement update Updated xorg-x11-drv-ati and mesa packages that fix a bug and add an enhancement are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-ati packages provide a driver for ATI graphics cards for the X.Org implementation of the X Window System. The mesa packages provide hardware-accelerated drivers for many popular graphics chipsets, and Mesa, a 3D graphics application programming interface (API) compatible with the Open Graphics Library (OpenGL). Bug Fix BZ# 821873 Previously, Mesa did not recognize Intel HD Graphics chipsets integrated into Intel E3-family processors. Consequently, these chipsets provided limited display resolutions and their graphics performance was low. This update adds support for these chipsets. As a result, the chipsets are recognized by Mesa and perform as expected. Enhancement BZ# 788166 , BZ# 788168 This update adds support for AMD FirePro M100 (alternatively referred to as AMD FirePro M2000), AMD Radeon HD 74xx Series, AMD Radeon HD 75xx Series, and AMD Radeon HD 76xx Series graphics cards, and the AMD FusionA integrated graphics processing unit. All users of xorg-x11-drv-ati and Mesa are advised to upgrade to these updated packages, which fix this bug and add this enhancement.

Commands:
23.5. Synchronizing the Clocks The phc2sys program is used to synchronize the system clock to the PTP hardware clock ( PHC ) on the NIC. The phc2sys service is configured in the /etc/sysconfig/phc2sys configuration file. The default setting in the /etc/sysconfig/phc2sys file is as follows: OPTIONS="-a -r" The -a option causes phc2sys to read the clocks to be synchronized from the ptp4l application. It will follow changes in the PTP port states, adjusting the synchronization between the NIC hardware clocks accordingly. The system clock is not synchronized, unless the -r option is also specified. If you want the system clock to be eligible to become a time source, specify the -r option twice. After making changes to /etc/sysconfig/phc2sys , restart the phc2sys service from the command line by issuing a command as root : Under normal circumstances, use service commands to start, stop, and restart the phc2sys service. When you do not want to start phc2sys as a service, you can start it from the command line. For example, enter the following command as root : The -a option causes phc2sys to read the clocks to be synchronized from the ptp4l application. If you want the system clock to be eligible to become a time source, specify the -r option twice. Alternately, use the -s option to synchronize the system clock to a specific interface's PTP hardware clock. For example: The -w option waits for the running ptp4l application to synchronize the PTP clock and then retrieves the TAI to UTC offset from ptp4l . Normally, PTP operates in the International Atomic Time ( TAI ) timescale, while the system clock is kept in Coordinated Universal Time ( UTC ). The current offset between the TAI and UTC timescales is 36 seconds. The offset changes when leap seconds are inserted or deleted, which typically happens every few years. The -O option needs to be used to set this offset manually when the -w is not used, as follows: Once the phc2sys servo is in a locked state, the clock will not be stepped, unless the -S option is used. This means that the phc2sys program should be started after the ptp4l program has synchronized the PTP hardware clock. However, with -w , it is not necessary to start phc2sys after ptp4l as it will wait for it to synchronize the clock. The phc2sys program can also be started as a service by running: When running as a service, options are specified in the /etc/sysconfig/phc2sys file. More information on the different phc2sys options can be found in the phc2sys(8) man page. Note that the examples in this section assume the command is run on a slave system or slave port.

Commands:
~]# service phc2sys restart
~]# phc2sys -a -r
~]# phc2sys -s eth3 -w
~]# phc2sys -s eth3 -O -36
~]# service phc2sys start
Chapter 1. Fixed issues 1.1. AMQ JMS ENTMQCL-2337 - Failure decoding large messages with special characters In earlier releases of the product, the client failed to decode messages containing multi-byte characters if the characters spanned transfer frames. In this release, large messages with multi-byte characters are correctly decoded. ENTMQCL-2339 - The client can ignore transactions right after failover In earlier releases of the product, the client sometimes failed to mark a message transfer as belonging to a transaction directly after connection failover. In this release, transactions are correctly recovered after failover. 1.2. AMQ .NET ENTMQCL-2241 - Client example sends empty begin frames In earlier releases of the product, the ReconnectSender example program sent an AMQP begin frame lacking required fields. In this release, the example correctly provides the mandatory fields. 1.3. AMQ C++ ENTMQCL-1863 - On receiving a forced close, send a corresponding protocol close and close the socket In earlier releases of the product, when the client received a forced AMQP connection close from the remote peer, it then closed its local TCP socket without sending a matching AMQP close in return. In this release, the client sends an AMQP close before closing the socket.

Commands:
Chapter 1. Overview Red Hat Quay includes the following features: High availability Geo-replication Repository mirroring Docker v2, schema 2 (multi-arch) support Continuous integration Security scanning with Clair Custom log rotation Zero downtime garbage collection 24/7 support Red Hat Quay provides support for the following: Multiple authentication and access methods Multiple storage backends Custom certificates for Quay, Clair, and storage backends Application registries Different container image types 1.1. Architecture Red Hat Quay includes several core components, both internal and external. 1.1.1. Internal components Red Hat Quay includes the following internal components: Quay (container registry) . Runs the Quay container as a service, consisting of several components in the pod. Clair . Scans container images for vulnerabilities and suggests fixes. 1.1.2. External components Red Hat Quay includes the following external components: Database . Used by Red Hat Quay as its primary metadata storage. Note that this is not for image storage. Redis (key-value store) . Stores live builder logs and the Red Hat Quay tutorial. Also includes the locking mechanism that is required for garbage collection. Cloud storage . For supported deployments, one of the following storage types must be used: Public cloud storage . In public cloud environments, you should use the cloud provider's object storage, such as Amazon Web Services's Amazon S3 or Google Cloud's Google Cloud Storage. Private cloud storage . In private clouds, an S3 or Swift compliant Object Store is needed, such as Ceph RADOS, or OpenStack Swift. Warning Do not use "Locally mounted directory" Storage Engine for any production configurations. Mounted NFS volumes are not supported. Local storage is meant for Red Hat Quay test-only installations.

Commands:
Chapter 3. Clustering The PCS cluster stop operation now completes successfully when cluster nodes include resources that require DLM When stopping the cluster on all nodes by running pcs cluster stop --all , resources that require the Distributed Lock Manager (DLM), such as gfs2 or clustered logical volumes, in some cases lost quorum before they were able to shut down. As a consequence, the stop operation became unresponsive. With this update, pcs cluster stop --all stops the cman service on all nodes only after Pacemaker has stopped those nodes. As a result, quorum is maintained while all resources are stopping, and the operation is thus able to complete successfully. (BZ# 1322595 , BZ#1353738) The rgmanager daemon can now correctly start clustered services on surviving nodes when quorum is regained With central processing mode enabled, when quorum was dissolved and regained, the rgmanager daemon stopped working on a surviving cluster node. With this update, the configuration tree is repopulated after quorum is regained. As a result, clustered services start up on the surviving cluster node as expected in the described scenario. (BZ#1084053) Short time between the start of rgmanager and clustat no longer leads to rgmanager crashing When the clustat utility was run shortly after the rgmanager daemon started but before it completely finished initializing, rgmanager was susceptible to unexpected termination. This bug has been fixed and rgmanager now starts without crashing in this scenario. (BZ#1228170) rgmanager exits without problems after cman is stopped When the cman service was stopped before the rgmanager daemon, rgmanager in some cases exited unexpectedly on cluster nodes. With this update, the cpg_lock() function has been fixed and rgmanager exits gracefully in the described scenario. (BZ#1342825) Time-related values of cluster resource configuration are now evaluated properly Previously, time-related resource values in actual use could differ from the values configured in the cluster.conf file, especially at the initial configuration load. This could cause the rgmanager daemon to behave unpredictably. With this fix, rgmanager behaves exactly as configured with regards to resources and respective time-related values. (BZ# 1414139 )

Commands:
8.121. libservicelog 8.121.1. RHBA-2014:1430 - libservicelog bug fix and enhancement update Updated libservicelog packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libservicelog packages provide a library for logging service-related events to the servicelog database, and a number of command-line utilities for viewing the contents of the database. Note The libservicelog packages have been upgraded to upstream version 1.1.13, which provides a number of bug fixes and enhancements over the version, including support for SQL insert command input string. (BZ# 739120 ) Users of libservicelog are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 2. Learn more about OpenShift Container Platform Use the following sections to find content to help you learn about and use OpenShift Container Platform. 2.1. Architect Learn about OpenShift Container Platform Plan an OpenShift Container Platform deployment Additional resources Enterprise Kubernetes with OpenShift Tested platforms OpenShift blog Architecture Security and compliance What's new in OpenShift Container Platform Networking OpenShift Container Platform life cycle Backup and restore 2.2. Cluster Administrator Learn about OpenShift Container Platform Deploy OpenShift Container Platform Manage OpenShift Container Platform Additional resources Enterprise Kubernetes with OpenShift Installing OpenShift Container Platform Using Insights to identify issues with your cluster Getting Support Architecture Post installation configuration Logging OpenShift Knowledgebase articles OpenShift Interactive Learning Portal Networking Monitoring OpenShift Container Platform Life Cycle Storage Backup and restore Updating a cluster 2.3. Application Site Reliability Engineer (App SRE) Learn about OpenShift Container Platform Deploy and manage applications Additional resources OpenShift Interactive Learning Portal Projects Getting Support Architecture Operators OpenShift Knowledgebase articles Logging OpenShift Container Platform Life Cycle Blogs about logging Monitoring 2.4. Developer Learn about application development in OpenShift Container Platform Deploy applications Getting started with OpenShift for developers (interactive tutorial) Creating applications Red Hat Developers site Builds Red Hat CodeReady Workspaces Operators Images Developer-focused CLI

Commands:
Chapter 8. HTTP configuration 8.1. Global HTTPS redirection HTTPS redirection provides redirection for incoming HTTP requests. These redirected HTTP requests are encrypted. You can enable HTTPS redirection for all services on the cluster by configuring the httpProtocol spec for the KnativeServing custom resource (CR). 8.1.1. HTTPS redirection global settings Example KnativeServing CR that enables HTTPS redirection apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: network: httpProtocol: "redirected" ... 8.2. HTTPS redirection per service You can enable or disable HTTPS redirection for a service by configuring the networking.knative.dev/http-option annotation. 8.2.1. Redirecting HTTPS for a service The following example shows how you can use this annotation in a Knative Service YAML object: apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example namespace: default annotations: networking.knative.dev/http-protocol: "redirected" spec: ... 8.3. Full duplex support for HTTP/1 You can enable the HTTP/1 full duplex support for a service by configuring the features.knative.dev/http-full-duplex annotation. Note Verify your HTTP clients before enabling, as earlier version clients might not provide support for HTTP/1 full duplex. The following example shows how you can use this annotation in a Knative Service YAML object at the revision spec level: Example KnativeServing CR that provides full duplex support for HTTP/1 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: spec: annotations: features.knative.dev/http-full-duplex: "Enabled" ...

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: network: httpProtocol: "redirected"
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example namespace: default annotations: networking.knative.dev/http-protocol: "redirected" spec:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: spec: annotations: features.knative.dev/http-full-duplex: "Enabled"
Chapter 21. Configuring emails in task notification Earlier it was possible to send notifications only to users or group of users in Business Central. Now you can directly add any email addresses as well. Prerequisites You have created a project in Business Central. Procedure Create a business process. For more information about creating a business process in Business Central, see Chapter 5, Creating a business process in Business Central . Create a user task. For more information about creating a user task in Business Central, see Section 5.4, "Creating user tasks" . In the upper-right corner of the screen, click the Properties icon. Expand Implementation/Execution and click to Notifications , to open the Notifications window. Click Add . In the Notifications window, enter an email address in the To: email(s) field to set the recipients of the task notification emails. You can add multiple email addresses separated by comma. Enter the subject and body of the email. Click Ok . You can see the added email addresses in the To: email(s) column in the Notifications window. Click Ok .

Commands:
9.6. Starting and Stopping NFS To run an NFS server, the rpcbind [3] service must be running. To verify that rpcbind is active, use the following command: If the rpcbind service is running, then the nfs service can be started. To start an NFS server, use the following command: nfslock must also be started for both the NFS client and server to function properly. To start NFS locking, use the following command: If NFS is set to start at boot, ensure that nfslock also starts by running chkconfig --list nfslock . If nfslock is not set to on , this implies that you will need to manually run the service nfslock start each time the computer starts. To set nfslock to automatically start on boot, use chkconfig nfslock on . nfslock is only needed for NFSv2 and NFSv3. To stop the server, use: The restart option is a shorthand way of stopping and then starting NFS. This is the most efficient way to make configuration changes take effect after editing the configuration file for NFS. To restart the server type: The condrestart ( conditional restart ) option only starts nfs if it is currently running. This option is useful for scripts, because it does not start the daemon if it is not running. To conditionally restart the server type: To reload the NFS server configuration file without restarting the service type:

Commands:
service rpcbind status
service nfs start
service nfslock start
service nfs stop
service nfs restart
service nfs condrestart
service nfs reload