mtpti5iD/redhat-docs_dataset huggingface dataset:
Part V. Installing and configuring KIE Server on IBM WebSphere Application Server As a system administrator, you can configure your IBM WebSphere Application Server for Red Hat KIE Server and install KIE Server on that IBM server instance. Note Support for Red Hat Process Automation Manager on IBM WebSphere Application Server is now in the maintenance phase. Red Hat will continue to support Red Hat Process Automation Manager on IBM WebSphere Application Server with the following limitations: Red Hat will not release new certifications or software functionality. Red Hat will release only qualified security patches that have a critical impact and mission-critical bug fix patches. In the future, Red Hat might direct customers to migrate to new platforms and product components that are compatible with the Red Hat hybrid cloud strategy. Prerequisites An IBM WebSphere Application Server instance version 9.0 or later is installed. For complete installation instructions, see the IBM WebSphere Application Server product page . You have access to the WebSphere Integrated Solutions Console, usually at http://<HOST>:9060/ibm/console .

Commands:
Appendix C. Revision History Note that revision numbers relate to the edition of this manual, not to version numbers of Red Hat Directory Server. 11.5-1 Tue May 10 2022, Marc Muehlfeld ( mmuehlfeld@redhat.com ) Red Hat Directory Server 11.5 release of this guide. 11.4-1 Tue Nov 09 2021, Marc Muehlfeld ( mmuehlfeld@redhat.com ) Red Hat Directory Server 11.4 release of this guide. 11.3-1 Tue May 11 2021, Marc Muehlfeld ( mmuehlfeld@redhat.com ) Red Hat Directory Server 11.3 release of this guide. 11.2-1 Tue Nov 03 2020, Marc Muehlfeld ( mmuehlfeld@redhat.com ) Red Hat Directory Server 11.2 release of this guide. 11.1-1 Tue Apr 28 2020, Marc Muehlfeld ( mmuehlfeld@redhat.com ) Red Hat Directory Server 11.1 release of this guide. 11.0-1 Tue Nov 05 2019, Marc Muehlfeld ( mmuehlfeld@redhat.com ) Red Hat Directory Server 11.0 release of this guide.

Commands:
Chapter 14. Red Hat Process Automation Manager Red Hat build of Kogito Operator interaction with Kafka The Red Hat Process Automation Manager Red Hat build of Kogito Operator uses the AMQ Streams Operator to automatically configure the Red Hat build of Kogito microservice with Kafka. When you enable an infrastructure mechanism through KogitoInfra deployment, the Red Hat Process Automation Manager Red Hat build of Kogito Operator uses the relevant third-party operator to configure the infrastructure. You must define your custom infrastructure resource and link it in the KogitoInfra file. You can specify your custom infrastructure resource in the spec.resource.name and spec.resource.namespace configurations. Example Red Hat Process Automation Manager Red Hat build of Kogito infrastructure resource for custom messaging apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoInfra # Application type metadata: name: my-kafka-infra spec: resource: apiVersion: kafka.strimzi.io/v1beta2 # AMQ Streams API kind: Kafka # AMQ Streams Application Type name: my-kafka-instance namespace: my-namespace In this example, the KogitoInfra custom resource connects to the Kafka cluster my-kafka-instance from my-namespace for event messaging. To connect Red Hat build of Kogito microservice to Kafka, you need to define the infra configuration to use the corresponding infrastructure. Example of Red Hat build of Kogito microservice resource configuration with messaging apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoRuntime # Application type metadata: name: example-quarkus # Application name spec: image: <final-image-name> # Kogito image name insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate infra: - my-kafka-infra The Red Hat Process Automation Manager Red Hat build of Kogito Operator configures the necessary properties so that your application can connect to the Kafka instance.

Commands:
apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoInfra # Application type metadata: name: my-kafka-infra spec: resource: apiVersion: kafka.strimzi.io/v1beta2 # AMQ Streams API kind: Kafka # AMQ Streams Application Type name: my-kafka-instance namespace: my-namespace
apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoRuntime # Application type metadata: name: example-quarkus # Application name spec: image: <final-image-name> # Kogito image name insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate infra: - my-kafka-infra
Chapter 14. System and Subscription Management Subscription Manager no longer crashes when nl_connect() is unable to establish a connection Previously, the open_netlink() function did not check the return code of the nl_connect() function, and the get_etherinfo() function did not check the return address of the rtnl_link_alloc_cache() function at the python-ethtool interface. Consequently, when nl_connect() was unable to establish a connection, Subscription Manager terminated unexpectedly with a segmentation fault. With this update, open_netlink() and get_etherinfo() check return values of nl_connect() and rtnl_link_alloc_cache() respectively, and Subscription Manager no longer crashes in the described scenario. (BZ#1032779) ps no longer removes do_ and sys_ prefixes Prior to this update, the ps command removed do_ and sys_ prefixes from the wait channel name when the wchan format option was used. As a conseqence, this caused ambiguities in some kernel function names. The bug has been fixed, and as a result the ps command no longer removes do_ and sys_ prefixes. (BZ# 1322111 )

Commands:
Chapter 1. Overview of OpenShift AI Red Hat OpenShift AI is a platform for data scientists and developers of artificial intelligence and machine learning (AI/ML) applications. OpenShift AI provides an environment to develop, train, serve, test, and monitor AI/ML models and applications on-premise or in the cloud. For data scientists, OpenShift AI includes Jupyter and a collection of default notebook images optimized with the tools and libraries required for model development, and the TensorFlow and PyTorch frameworks. Deploy and host your models, integrate models into external applications, and export models to host them in any hybrid cloud environment. You can enhance your data science projects on OpenShift AI by building portable machine learning (ML) workflows with data science pipelines, using Docker containers. You can also accelerate your data science experiments through the use of graphics processing units (GPUs) and Intel Gaudi AI accelerators. For administrators, OpenShift AI enables data science workloads in an existing Red Hat OpenShift or ROSA environment. Manage users with your existing OpenShift identity provider, and manage the resources available to notebook servers to ensure data scientists have what they require to create, train, and host models. Use accelerators to reduce costs and allow your data scientists to enhance the performance of their end-to-end data science workflows using graphics processing units (GPUs) and Intel Gaudi AI accelerators. OpenShift AI has two deployment options: Self-managed software that you can install on-premise or in the cloud. You can install OpenShift AI Self-Managed in a self-managed environment such as OpenShift Container Platform, or in Red Hat-managed cloud environments such as Red Hat OpenShift Dedicated (with a Customer Cloud Subscription for AWS or GCP), Red Hat OpenShift Service on Amazon Web Services (ROSA Classic or ROSA HCP), or Microsoft Azure Red Hat OpenShift. A managed cloud service , installed as an add-on in Red Hat OpenShift Dedicated (with a Customer Cloud Subscription for AWS or GCP) or in Red Hat OpenShift Service on Amazon Web Services (ROSA Classic). For information about OpenShift AI Cloud Service, see Product Documentation for Red Hat OpenShift AI . For information about OpenShift AI supported software platforms, components, and dependencies, see the Red Hat OpenShift AI: Supported Configurations Knowledgebase article. For a detailed view of the 2.18 release lifecycle, including the full support phase window, see the Red Hat OpenShift AI Self-Managed Life Cycle Knowledgebase article.

Commands:
Preface If you're using GitHub Actions for your application, pipeline runs may fail due to missing secrets. Without them, integrations with Quay, JFrog, and Red Hat Advanced Cluster Security (ACS) won't work, breaking security tasks like vulnerability scanning, image signing, and SBOM generation for compliance. To prevent this, you need to securely store secrets in GitHub Actions. This guide walks you through the process, ensuring your pipelines run smoothly and securely.

Commands:
Chapter 8. Vault SPI 8.1. Vault provider You can use a vault SPI from org.keycloak.vault package to write custom extension for Red Hat Single Sign-On to connect to arbitrary vault implementation. The built-in files-plaintext provider is an example of the implementation of this SPI. In general the following rules apply: To prevent a secret from leaking across realms, you may want to isolate or limit the secrets that can be retrieved by a realm. In that case, your provider should take into account the realm name when looking up secrets, for example by prefixing entries with the realm name. For example, an expression USD{vault.key} would then evaluate generally to different entry names, depending on whether it was used in a realm A or realm B . To differentiate between realms, the realm needs to be passed to the created VaultProvider instance from VaultProviderFactory.create() method where it is available from the KeycloakSession parameter. The vault provider needs to implement a single method obtainSecret that returns a VaultRawSecret for the given secret name. That class holds the representation of the secret either in byte[] or ByteBuffer and is expected to convert between the two upon demand. Note that this buffer would be discarded after usage as explained below. For details on how to package and deploy a custom provider refer to the Service Provider Interfaces chapter. 8.2. Consuming values from vault The vault contains sensitive data and Red Hat Single Sign-On treats the secrets accordingly. When accessing a secret, the secret is obtained from the vault and retained in JVM memory only for the necessary time. Then all possible attempts to discard its content from JVM memory is done. This is achieved by using the vault secrets only within try -with-resources statement as outlined below: char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage The example uses KeycloakSession.vault() as the entrypoint for accessing the secrets. Using the VaultProvider.obtainSecret method directly is indeed also possible. However the vault() method has the benefit of ability to interpret the raw secret (which is generally a byte array) as a character array (via vault().getCharSecret() ) or a String (via vault().getStringSecret() ) in addition to obtaining the original uninterpreted value (via vault().getRawSecret() method). Note that since String objects are immutable, their content cannot be discarded by overriding with random garbage. Even though measures have been taken in the default VaultStringSecret implementation to prevent internalizing String s, the secrets stored in String objects would live at least to the GC round. Thus using plain byte and character arrays and buffers is preferable.

Commands:
char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage
Chapter 6. Changes in Go Toolset Go Toolset has been updated from version 1.20 to 1.21.0 on RHEL 8 and RHEL 9. Notable changes include: min , max , and clear built-ins have been added. Package initialization order is more precisely defined. Type inferencing is improved. Changes to loop variable semantics. Backwards compatibility support is improved. For detailed information regarding the updates, see the upstream Go 1.21 Release Notes .

Commands:
33.12. Saving the File To review the contents of the kickstart file after you have finished choosing your kickstart options, select File => Preview from the pull-down menu. Figure 33.15. Preview To save the kickstart file, click the Save to File button in the preview window. To save the file without previewing it, select File => Save File or press Ctrl + S . A dialog box appears. Select where to save the file. After saving the file, refer to Section 32.11, "Starting a Kickstart Installation" for information on how to start the kickstart installation.

Commands:
Chapter 6. Clustering Pacemaker now supports path , mount , and timer systemd unit files Previously, Pacemaker supported service and socket systemd unit files, but any other unit file type would be treated as a service unit and fail. With this release, path , mount , and timer systemd units can now be managed by a Pacemaker cluster. (BZ#1590483) Support for Red Hat Enterprise Linux High Availability clusters on Alibaba Cloud Red Hat Enterprise Linux 7.6 supports High Availability clusters of virtual machines (VMs) on Alibaba Cloud (Aliyun). For information on configuring a Red Hat Enterprise Linux High Availability Cluster on Alibaba Cloud, see https://access.redhat.com/articles/3467251 . (BZ#1568589) Support for Red Hat Enterprise Linux high availability clusters on Google Compute Cloud Red Hat Enterprise Linux 7.6 supports high availability clusters of virtual machines (VMs) on Google Compute Cloud (GCP). For information on configuring a Red Hat Enterprise Linux High Availability Cluster on GCP, see https://access.redhat.com/articles/3479821 . (BZ#1568588) New volume_group_check_only parameter for lvm resource agent The lvm resource agent now supports the volume_group_check_only parameter. When this parameter is set, only the volume group is checked when running a monitoring operation. Setting this parameter can be used to avoid timeouts with tagged volumes. WARNING: This parameter should be used only when you have issues with timeouts, and when you must use the lvm resource agent and not the LVM-activate agent. (BZ#1470840) Support for VDO resource agent Red Hat Enterprise Linux now provides support for the vdo-vol resource agent to manage VDO (Virtual Data Optimizer) volumes as a high availability resource. (BZ#1538689) The pcs command now supports filtering resource failures by an operation and its interval Pacemaker now tracks resource failures per a resource operation on top of a resource name, and a node. The pcs resource failcount show command now allows filtering failures by a resource, node, operation, and interval. It provides an option to display failures aggregated per a resource and node or detailed per a resource, node, operation, and its interval. Additionally, the pcs resource failcount reset command now allows filtering failures by a resource, node, operation, and interval. (BZ# 1427273 ) New pcs commands to list available watchdog devices and test watchdog devices In order to configure SBD with Pacemaker, a functioning watchdog device is required. The Red Hat Enterprise Linux 7.6 release supports the pcs stonith sbd watchdog list command to list available watchdog devices on the local node, and the pcs stonith sbd watchdog test command to test a watchdog device. (BZ#1475318)

Commands:
14.12. Supported qemu-img Formats When a format is specified in any of the qemu-img commands, the following format types may be used: raw - Raw disk image format (default). This can be the fastest file-based format. If your file system supports holes (for example in ext2 or ext3 ), then only the written sectors will reserve space. Use qemu-img info to obtain the real size used by the image or ls -ls on Unix/Linux. Although Raw images give optimal performance, only very basic features are available with a Raw image. For example, no snapshots are available. qcow2 - QEMU image format, the most versatile format with the best feature set. Use it to have optional AES encryption, zlib-based compression, support of multiple VM snapshots, and smaller images, which are useful on file systems that do not support holes . Note that this expansive feature set comes at the cost of performance. Although only the formats above can be used to run on a guest virtual machine or host physical machine, qemu-img also recognizes and supports the following formats in order to convert from them into either raw , or qcow2 format. The format of an image is usually detected automatically. In addition to converting these formats into raw or qcow2 , they can be converted back from raw or qcow2 to the original format. Note that the qcow2 version supplied with Red Hat Enterprise Linux 7 is 1.1. The format that is supplied with versions of Red Hat Enterprise Linux will be 0.10. You can revert image files to versions of qcow2. To know which version you are using, run qemu-img info qcow2 [imagefilename.img] command. To change the qcow version see Section 23.19.2, "Setting Target Elements" . bochs - Bochs disk image format. cloop - Linux Compressed Loop image, useful only to reuse directly compressed CD-ROM images present for example in the Knoppix CD-ROMs. cow - User Mode Linux Copy On Write image format. The cow format is included only for compatibility with versions. dmg - Mac disk image format. nbd - Network block device. parallels - Parallels virtualization disk image format. qcow - Old QEMU image format. Only included for compatibility with older versions. qed - Old QEMU image format. Only included for compatibility with older versions. vdi - Oracle VM VirtualBox hard disk image format. vhdx - Microsoft Hyper-V virtual hard disk-X disk image format. vmdk - VMware 3 and 4 compatible image format. vvfat - Virtual VFAT disk image format.

Commands:
Chapter 1. Introduction to source-to-image for OpenShift OpenShift Container Platform provides an source-to-image (S2I) process to build and run applications. You can attach the application's source code on top of a builder image (a technology image such as JBoss EAP). S2I process builds your application and layers it on top of the builder image to create an application image. After your application image is built, you can push it to an integrated registry inside OpenShift or to a standalone registry . With S2I for OpenShift you can build and run basic Java applications, for example, fat-jar or flat classpath within a containerized image on OpenShift. 1.1. Image stream definitions By default, the Red Hat OpenShift Container Platform includes image streams that contain the Red Hat build of OpenJDK container images. You can import image stream definitions into a new namespace or recreate them. You can access these image stream templates on the openjdk GitHub page. Red Hat OpenShift Container Platform includes java as an image stream, which follows the latest version of the container image. This image stream contains the following tags: :latest , which provides the latest supported Red Hat build of OpenJDK version. A tag tracks any updates for this image stream. :11 , which provides latest JDK 11 images. :8 , which provides the latest JDK 8 images. The image stream and its tags are based on the latest version of the RHEL Universal Base Image (UBI). Note If you want to select a specific RHEL or Red Hat build of OpenJDK version, select a tag with the openjdk-X-ubiY format, where X refers to the Red Hat build of OpenJDK version and Y refers to the RHEL version. The following examples demonstrate tags that follow this format: openjdk-8-ubi8 openjdk-11-ubi8 openjdk-17-ubi8 Specific image streams exist to accurately track the latest container image versions. These image streams follow the ubiX-openjdk-Y format, where X specifies the RHEL UBI version and Y specifies the Red Hat build of OpenJDK version. The following examples demonstrate image streams that follow this format: ubi8-openjdk-8 ubi8-openjdk-11 ubi8-openjdk-17 The tags for these image streams map directly to the image versions, such as 1.11 , 1.12 , and so on. Additional resources Managing image streams (OpenShift Container Platform) templates (GitHub)

Commands:
Preface Open Java Development Kit (OpenJDK) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). Eclipse Temurin is available in four LTS versions: OpenJDK 8u, OpenJDK 11u, OpenJDK 17u, and OpenJDK 21u. Binary files for Eclipse Temurin are available for macOS, Microsoft Windows, and multiple Linux x86 Operating Systems including Red Hat Enterprise Linux and Ubuntu.

Commands:
8.187. pulseaudio 8.187.1. RHBA-2014:0750 - pulseaudio bug fix update Updated pulseaudio packages that fix one bug are now available for Red Hat Enterprise Linux 6. PulseAudio is a sound server for Linux, UNIX, and similar operating systems. Bug Fix BZ# 1095750 Due to limited support of the pulseaudio server for multiple High-Definition Multi-media Interface (HDMI) devices per sound card, audio would previously sometimes not function properly on specific Intel and Nvidia configurations, such as the Haswell microarchitecture processors. With this update, the support for multiple HDMI devices per sound card has been implemented for pulseaudio, and HDMI audio output now works in the described scenarios as expected. Users of pulseaudio are advised to upgrade to these updated packages, which fix this bug.

Commands:
Preface Red Hat OpenShift Data Foundation supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) using Red Hat OpenStack Platform clusters. Note Both internal and external OpenShift Data Foundation clusters are supported on Red Hat OpenStack Platform. See Planning your deployment for more information about deployment requirements. To deploy OpenShift Data Foundation, start with the requirements in Preparing to deploy OpenShift Data Foundation chapter and then follow the appropriate deployment process based on your requirement: Internal mode Deploying OpenShift Data Foundation on Red Hat OpenStack Platform in internal mode Deploy standalone Multicloud Object Gateway component External mode Deploying OpenShift Data Foundation on Red Hat OpenStack Platform in external mode

Commands: