mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Development workflow RHTAP integrates security at every step of the DevSecOps workflow: Start with secure templates: Leverage pre-built templates from Red Hat Developer Hub (RHDH) for a secure foundation. These templates include code repositories, documentation, and pre-configured CI/CD pipelines. Develop and modify code: Modify your code after creating the application. Each code change triggers a pipeline that automatically performs security checks, including artifact signing, vulnerability scanning, and SBOM generation. OpenShift GitOps driven deployment: RHTAP enforces security policies throughout the development lifecycle, from development to production, using Enterprise Contracts (EC). This ensures that only compliant builds are deployed. step Getting Started with Red Hat Trusted Application Pipeline . Additional Resources Red Hat Developer Hub Documentation Red Hat Trusted Artifact Signer Deployment Guide Red Hat Trusted Profile Analyzer Documentation Revised on 2025-02-06 17:38:03 UTC

Commands:
Chapter 2. Registering your host This section explains how to register your RHEL server to Red Hat Satellite. Note Different steps apply if your system is registered to the Red Hat Customer Portal or your Cloud provider. Prerequisites You have a valid Red Hat Enterprise Linux for SAP Solutions subscription. You must have a valid RHEL for SAP Solutions subscription so your server has access to required packages via a Red Hat Satellite server, the Red Hat Customer Portal, or your Cloud provider. For more information, see Red Hat Satellite > 6.8 > Quick Start Guide . You have the following information provided to you by your Satellite administrator: An activation key. A string representing the name of the organization. A URL for the Katello client package. This is required for attaching your server to a Satellite server. For more information, see Red Hat Satellite > 6.8 > Quick Start Guide . Your server meets the hardware requirements or Infrastructure as a Sercice (IaaS) configurations. For bare metal deployment, verify that your server type is mentioned in the SAP Certified and Supported SAP HANA Hardware Directory and that it matches the minimum hardware requirements in the SAP HANA Server Installation and Update Guide . For certifiyed IaaS Platforms, see Certified and Supported SAP HANA Hardware . root access. Procedure Download the Katello client rpm package: Replace the URL with the URL provided by your Satellite administrator. Install the Katello client rpm package: Replace the package name with the name of the package you downloaded. Register your system: Replace your-organization-name with the string representing the name of the organization and replace your-activation-key with the activation key. Both are provided by your Satellite administrator. Note If you are using an external Ansible control node to register and subscribe your RHEL server to RHEL for SAP Solutions repositories, you can utilize redhat_sap.sap_rhsm ansible role instead of registering your system manually. For more information, see sap_rhsm section on the Ansible Galaxy portal.

Commands:
wget https://sat.int.example.com/pub/katello-ca-consumer-latest.noarch.rpm
yum install -y katello-ca-consumer-latest.noarch.rpm
subscription-manager register --org=" your-organization-name " --activationkey=" your-activation-key "
Chapter 1. Introduction 1.1. About the Rule Development Guide This guide is intended for software engineers who want to create custom YAML-based rules for Migration Toolkit for Applications (MTA) tools. See the Introduction to the Migration Toolkit for Applications for an overview and the CLI Guide for details. 1.1.1. Use of <MTA_HOME> in this guide This guide uses the <MTA_HOME> replaceable variable to denote the path to your MTA installation. The mta-7.2.1-cli<OS>.zip* extracts a single binary called mta-cli . When you encounter <MTA_HOME> in this guide, replace it with the actual path to your MTA installation. 1.2. The MTA rules The Migration Toolkit for Applications (MTA) contains rule-based migration tools (analyzers) that you can use to analyze the application user interfaces (APIs), technologies, and architectures used by the applications you plan to migrate. MTA analyzer rules use the following rule pattern: You can use the MTA rules internally to perform the following tasks: Extract files from archives. Decompile files. Scan and classify file types. Analyze XML and other file content. Analyze the application code. Build the reports. MTA builds a data model based on the rule execution results and stores component data and relationships in a graph database. This database can then be queried and updated as required by the migration rules and for reporting purposes. Note You can create your own custom analyzer rules. You can use custom rules to identify the use of custom libraries or other components that might not be covered by the provided standard migration rules.

Commands:
when(condition) message(message) tag(tags)
2.6. Specify Configuration Properties in an ra.xml File Every configuration property defined inside the new Managed Connection Factory class must also be configured in the ra.xml file. These properties are used to configure each instance of the connector. An example file is provided in Section A.1, "Template for ra.xml" . The following is the format for a single entry: <config-property> <description> {USDdisplay:"display-name",USDdescription:"description", USDallowed:"allowed", USDrequired:"true|false", USDdefaultValue:"default-value"} </description> <config-property-name>property-name</config-property-name> <config-property-type>property-type</config-property-type> <config-property-value>optional-property-value</config-property-value> </config-property> For example: <config-property> <description> {USDdisplay:"User Name",USDdescription:"The name of the user.", USDrequired="true"} </description> <config-property-name>UserName</config-property-name> <config-property-type>java.lang.String</config-property-type> </config-property> The format and contents of the <description> element may be used as extended metadata for tooling. This use of the special format and all properties is optional and must follow these rules: The special format must begin and end with curly braces e.g. { } . Property names begin with USD . Property names and the associated value are separated with a colon ( : ). Double quotes ( " ) identifies a single value. A pair of square brackets ( [ ] ), containing comma separated double quoted entries indicates a list value. The following are optional properties: USDdisplay : Display name of the property. USDdescription : Description about the property. USDrequired : The property is a required property; or optional and a default is supplied. USDallowed : If property value must be in certain set of legal values, this defines all the allowed values. USDmasked : The tools need to mask the property; Do not show in plain text; used for passwords. USDadvanced : Notes this as Advanced property. USDreadOnly : Property is set to read-only. Note Although these are optional properties, in the absence of this metadata, Red Hat JBoss Data Virtualization tooling may not work as expected. Note You can also undertake the process using the maven archetype .

Commands:
<config-property> <description> {USDdisplay:"display-name",USDdescription:"description", USDallowed:"allowed", USDrequired:"true|false", USDdefaultValue:"default-value"} </description> <config-property-name>property-name</config-property-name> <config-property-type>property-type</config-property-type> <config-property-value>optional-property-value</config-property-value> </config-property>
<config-property> <description> {USDdisplay:"User Name",USDdescription:"The name of the user.", USDrequired="true"} </description> <config-property-name>UserName</config-property-name> <config-property-type>java.lang.String</config-property-type> </config-property>
20.16.11. Hub Devices A hub is a device that expands a single port into several so that there are more ports available to connect devices to a host physical machine system. To specify the hub devices configuration settings, use a management tool to make the following changes to the domain XML: ... <devices> <hub type='usb'/> </devices> ... Figure 20.55. Hub devices The hub element has one mandatory attribute, the type whose value can only be usb . The hub element has an optional sub-element address with type='usb' which can tie the device to a particular controller.

Commands:
<devices> <hub type='usb'/> </devices>
Chapter 7. Fixed Common Vulnerabilities and Exposures This section details Common Vulnerabilities and Exposures (CVEs) fixed in the AMQ Broker 7.10 release. ENTMQBR-5140 - CVE-2019-10744 nodejs-lodash: prototype pollution in defaultsDeep function leading to modifying properties ENTMQBR-5893 - CVE-2021-4040 broker: AMQ Broker: Malformed message can result in partial DoS (OOM) ENTMQBR-5933 - CVE-2021-43797 netty: control chars in header names may lead to HTTP request smuggling ENTMQBR-6401 - CVE-2022-23913 artemis-commons: Apache ActiveMQ Artemis DoS ENTMQBR-6477 - CVE-2020-36518 jackson-databind: denial of service via a large depth of nested objects

Commands:
Chapter 4. Migration of information from a deployment on Red Hat OpenShift Container Platform 3 If you previously used a Red Hat Decision Manager deployment on Red Hat OpenShift Container Platform 3, you can migrate the information from that deployment to a new deployment on Red Hat OpenShift Container Platform 4. Before migrating information, you must deploy a new Red Hat Decision Manager infrastructure on Red Hat OpenShift Container Platform 4 using the operator. Include the same elements in the new infrastructure as those present in the old deployment. For example: For any existing authoring deployment, create a new authoring infrastructure, including Business Central and at least one KIE Server. For any existing immutable KIE Server, deploy a new immutable KIE Server with the same artifacts. 4.1. Migrating information in Business Central If you have an existing authoring environment in Red Hat OpenShift Container Platform 3, you can copy the .niogit repository and the Maven repository from Business Central in this environment to Business Central in a new deployment on Red Hat OpenShift Container Platform 4. This action makes all the same projects and artifacts available in the new deployment. Prerequisites You must have a machine that has network access to both the Red Hat OpenShift Container Platform 3 and Red Hat OpenShift Container Platform 4 infrastructures. The oc command-line client from Red Hat OpenShift Container Platform 4 must be installed on the machine. For instructions about installing the command-line client, see CLI tools in Red Hat OpenShift Container Platform documentation. Procedure Ensure that no web clients and no client applications are connected to any elements of the old and new deployment, including Business Central and KIE Servers. Create an empty temporary directory and change into it. Using the oc command, log in to the Red Hat OpenShift Container Platform 3 infrastructure and switch to the project containing the old deployment. To view the pod names in the old deployment, run the following command: Find the Business Central pod. The name of this pod includes rhpamcentr . In a high-availability deployment, you can use any of the Business Central pods. Use the oc command to copy the .niogit repository and the Maven repository from the pod to the local machine, for example: Using the oc command, log in to the Red Hat OpenShift Container Platform 4 infrastructure and switch to the project containing the new deployment. To view the pod names in the new deployment, run the following command: Find the Business Central pod. The name of this pod includes rhpamcentr . In a high-availability deployment, you can use any of the Business Central pods. Use the oc command to copy the .niogit repository and the Maven repository from the local machine to the pod, for example:

Commands:
get pods
cp myapp-rhpamcentr-5-689mw:/opt/kie/data/.niogit .niogit cp myapp-rhpamcentr-5-689mw:/opt/kie/data/maven-repository maven-repository
get pods
cp .niogit myappnew-rhpamcentr-abd24:/opt/kie/data/.niogit cp maven-repository myappnew-rhpamcentr-abd24:/opt/kie/data/maven-repository
B.12. cvs B.12.1. RHSA-2010:0918 - Moderate: cvs security update An updated cvs package that fixes one security issue is now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Concurrent Version System (CVS) is a version control system that can record the history of your files. CVE-2010-3846 An array index error, leading to a heap-based buffer overflow, was found in the way CVS applied certain delta fragment changes from input files in the RCS (Revision Control System file) format. If an attacker in control of a CVS repository stored a specially-crafted RCS file in that repository, and then tricked a remote victim into checking out (updating their CVS repository tree) a revision containing that file, it could lead to arbitrary code execution with the privileges of the CVS server process on the system hosting the CVS repository. Red Hat would like to thank Ralph Loader for reporting this issue. All users of cvs are advised to upgrade to this updated package, which contains a backported patch to correct this issue.

Commands:
Chapter 25. System and Subscription Management ReaR works only on the eth0 interface ReaR produces a rescue system that does not support mounting an NFS server using an interface other than eth0. Consequently, the backup files cannot be downloaded and the system cannot be restored. To work around this problem, ensure that the used interface is eth0 by restarting dhclient. (BZ# 1313417 ) ReaR creates two ISO images instead of one In ReaR, the OUTPUT_URL directive enables specifying location for the ISO image containing the rescue system. Currently, with this directive set, ReaR creates two copies of the ISO image: one in the specified directory and one in the /var/lib/rear/output/ default directory. This requires additional space for the image. This is especially important if a full-system backup is included into the ISO image (using the BACKUP=NETFS and BACKUP_URL=iso:///backup/ configuration). To work around this behavior, delete the extra ISO image once ReaR has finished working or, to avoid having a period of time with double storage consumption, create the image in the default directory and then move it to the desired location manually. There is a request for enhancement to change this behavior and make ReaR create only one copy of the ISO image. (BZ#1320551)

Commands:
Chapter 1. Overview AMQ JMS Pool is a library that provides caching of JMS connections, sessions, and message producers. It enables reuse of connection resources beyond the standard lifecycle defined by the JMS API. AMQ JMS Pool operates as a standard JMS ConnectionFactory instance that wraps the ConnectionFactory of your chosen JMS provider and manages the lifetime of Connection objects from that provider based on the configuration of the JMS pool. It can be configured to share one or more connections among callers to the pool createConnection() methods. AMQ JMS Pool is part of AMQ Clients, a suite of messaging libraries supporting multiple languages and platforms. For an overview of the clients, see AMQ Clients Overview . For information about this release, see AMQ Clients 2.9 Release Notes . AMQ JMS Pool is based on the Pooled JMS messaging library. 1.1. Key features JMS 1.1 and 2.0 compatible Automatic reconnect Configurable connection and session pool sizes 1.2. Supported standards and protocols AMQ JMS Pool supports version 2.0 of the Java Message Service API. 1.3. Supported configurations AMQ JMS Pool supports the OS and language versions listed below. For more information, see Red Hat AMQ 7 Supported Configurations . Red Hat Enterprise Linux 7 and 8 with the following JDKs: OpenJDK 8 and 11 Oracle JDK 8 IBM JDK 8 IBM AIX 7.1 with IBM JDK 8 Microsoft Windows 10 Pro with Oracle JDK 8 Microsoft Windows Server 2012 R2 and 2016 with Oracle JDK 8 Oracle Solaris 10 and 11 with Oracle JDK 8 1.4. Document conventions The sudo command In this document, sudo is used for any command that requires root privileges. Exercise caution when using sudo because any changes can affect the entire system. For more information about sudo , see Using the sudo command . File paths In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/andrea ). On Microsoft Windows, you must use the equivalent Windows paths (for example, C:\Users\andrea ). Variable text This document contains code blocks with variables that you must replace with values specific to your environment. Variable text is enclosed in arrow braces and styled as italic monospace. For example, in the following command, replace <project-dir> with the value for your environment: USD cd <project-dir>

Commands:
cd <project-dir>
11.5. Configuring Transport Types for a Volume A volume can support one or more transport types for communication between clients and brick processes. There are three types of supported transport, which are, tcp, rdma, and tcp,rdma. To change the supported transport types of a volume, follow the procedure: Unmount the volume on all the clients using the following command: Stop the volumes using the following command: Warning Using RDMA as a transport protocol is considered deprecated in Red Hat Gluster Storage 3.5. Red Hat no longer recommends its use, and does not support it on new deployments and existing deployments that upgrade to Red Hat Gluster Storage 3.5.3. Change the transport type. For example, to enable both tcp and rdma execute the followimg command: Mount the volume on all the clients. For example, to mount using rdma transport, use the following command:

Commands:
umount mount-point
gluster volume stop volname
gluster volume set volname config.transport tcp,rdma OR tcp OR rdma
mount -t glusterfs -o transport=rdma server1:/test-volume /mnt/glusterfs
5.3. Main Configuration File The /etc/selinux/config file is the main SELinux configuration file. It controls whether SELinux is enabled or disabled and which SELinux mode and SELinux policy is used: SELINUX= The SELINUX option sets whether SELinux is disabled or enabled and in which mode - enforcing or permissive - it is running: When using SELINUX=enforcing , SELinux policy is enforced, and SELinux denies access based on SELinux policy rules. Denial messages are logged. When using SELINUX=permissive , SELinux policy is not enforced. SELinux does not deny access, but denials are logged for actions that would have been denied if running SELinux in enforcing mode. When using SELINUX=disabled , SELinux is disabled (the SELinux module is not registered with the Linux kernel), and only DAC rules are used. SELINUXTYPE= The SELINUXTYPE option sets the SELinux policy to use. Targeted policy is the default policy. Only change this option if you want to use the MLS policy. For information on how to enable the MLS policy, refer to Section 5.11.2, "Enabling MLS in SELinux" .

Commands:
This file controls the state of SELinux on the system. SELINUX= can take one of these three values: enforcing - SELinux security policy is enforced. permissive - SELinux prints warnings instead of enforcing. disabled - No SELinux policy is loaded. SELINUX=enforcing SELINUXTYPE= can take one of these two values: targeted - Targeted processes are protected, mls - Multi Level Security protection. SELINUXTYPE=targeted
Chapter 1. Uploading a collection to automation hub Prerequisites You have configured the ansible-galaxy client for automation hub. You have at least one namespace. You have run all content through ansible-test sanity . You are a Red Hat Connect Partner. Learn more at Red Hat Partner Connect . Procedure To upload your collection using the automation hub user interface: Log in to Red Hat Ansible Automation Platform. Go to Automation Hub My Namespaces . Click a namespace. Click Upload collection . In the New collection modal, click Select file . Locate the file on your system. Click Upload . To upload a collection using the ansible-galaxy client, enter the following command: ansible-galaxy collection publish path/to/my_namespace-my_collection-1.0.0.tar.gz --api-key=SECRET Once uploaded, your collections will enter the partner certification process. Our Partner Engineering team will contact you with the certification status of your collection.

Commands:
ansible-galaxy collection publish path/to/my_namespace-my_collection-1.0.0.tar.gz --api-key=SECRET
3.3. Resource Trees - Basics / Definitions The following illustrates the structure of a resource tree, with a corresponding list that defines each area. Resource trees are XML representations of resources, their attributes, parent/child and sibling relationships. The root of a resource tree is almost always a special type of resource called a service. Resource tree, resource group, and service are usually used interchangeably on this wiki. From RGManager's perspective, a resource tree is an atomic unit. All components of a resource tree are started on the same cluster node. fs:myfs and ip:10.1.1.2 are siblings fs:myfs is the parent of script:script_child script:script_child is the child of fs:myfs 3.3.1. Parent / Child Relationships, Dependencies, and Start Ordering The rules for parent/child relationships in the resource tree are fairly simple: Parents are started before children Children must all stop (cleanly) before a parent may be stopped From these two, you could say that a child resource is dependent on its parent resource In order for a resource to be considered in good health, all of its dependent children must also be in good health

Commands:
<service name="foo" ...> <fs name="myfs" ...> <script name="script_child"/> </fs> <ip address="10.1.1.2" .../> </service>
Chapter 10. The Asynchronous API In addition to synchronous API methods, Red Hat JBoss Data Grid also offers an asynchronous API that provides the same functionality in a non-blocking fashion. The asynchronous method naming convention is similar to their synchronous counterparts, with Async appended to each method name. Asynchronous methods return a Future that contains the result of the operation. For example, in a cache parameterized as Cache<String, String> , Cache.put(String key, String value) returns a String, while Cache.putAsync(String key, String value) returns a Future<String> . Report a bug 10.1. Asynchronous API Benefits The asynchronous API does not block, which provides multiple benefits, such as: The guarantee of synchronous communication, with the added ability to handle failures and exceptions. Not being required to block a thread's operations until the call completes. These benefits allow you to better harness the parallelism in your system, for example: Example 10.1. Using the Asynchronous API In the example, The following lines do not block the thread as they execute: futures.add(cache.putAsync( key1 , value1 )); futures.add(cache.putAsync( key2 , value2 )); futures.add(cache.putAsync( key3 , value3 )); The remote calls from the three put operations are executed in parallel. This is particularly useful when executed in distributed mode. Report a bug

Commands:
Set<Future<?>> futures = new HashSet<Future<?>>(); futures.add(cache.putAsync("key1", "value1")); futures.add(cache.putAsync("key2", "value2")); futures.add(cache.putAsync("key3", "value3"));