mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. Adding execution nodes to Red Hat Ansible Automation Platform Operator You can enable the Ansible Automation Platform Operator with execution nodes by downloading and installing the install bundle. Prerequisites An automation controller instance. The receptor collection package is installed. The Ansible Automation Platform repository ansible-automation-platform-2.5-for-rhel-{RHEL-RELEASE-NUMBER}-x86_64-rpms is enabled. Procedure Log in to Red Hat Ansible Automation Platform. In the navigation panel, select Automation Execution Infrastructure Instances . Click Add . Input the Execution Node domain name or IP in the Host Name field. Optional: Input the port number in the Listener Port field. Click Save . Click the download icon to Install Bundle . This starts a download, take note of where you save the file Untar the gz file. Note To run the install_receptor.yml playbook you must install the receptor collection from Ansible Galaxy: Ansible-galaxy collection install -r requirements.yml Update the playbook with your user name and SSH private key file. Note that ansible_host pre-populates with the hostname you input earlier. all: hosts: remote-execution: ansible_host: example_host_name # Same with configured in AAP WebUI ansible_user: <username> #user provided Ansible_ssh_private_key_file: ~/.ssh/id_example Open your terminal, and navigate to the directory where you saved the playbook. To install the bundle run: ansible-playbook install_receptor.yml -i inventory.yml When installed you can now upgrade your execution node by downloading and re-running the playbook for the instance you created. Verification To verify receptor service status run the following command: sudo systemctl status receptor.service Make sure the service is in active (running) state To verify if your playbook runs correctly on your new node run the following command: watch podman ps Additional resources For more information about managing instance groups see the Managing Instance Groups section of the Automation Controller User Guide.

Commands:
all: hosts: remote-execution: ansible_host: example_host_name # Same with configured in AAP WebUI ansible_user: <username> #user provided Ansible_ssh_private_key_file: ~/.ssh/id_example
ansible-playbook install_receptor.yml -i inventory.yml
sudo systemctl status receptor.service
watch podman ps
Chapter 1. Introduction to performance tuning A JBoss EAP installation is optimized by default. However, configurations to your environment, applications, and use of JBoss EAP subsystems can impact performance, meaning additional configuration might be needed. This guide provides optimization recommendations for common JBoss EAP use cases, as well as instructions for monitoring performance and diagnosing performance issues. Important You should stress test and verify all performance configuration changes under anticipated conditions in a staging or testing environment prior to deploying them to production. 1.1. About the use of EAP_HOME in this document In this document, the variable EAP_HOME is used to denote the path to the JBoss EAP installation. Replace this variable with the actual path to your JBoss EAP installation. If you installed the JBoss EAP compressed file, the install directory is the jboss-eap-8.0 directory where you extracted the compressed archive. If you used the installer to install JBoss EAP, the default path for EAP_HOME is USD{user.home}/EAP-8.0.0 : For Red Hat Enterprise Linux and Solaris: /home/ USER_NAME /EAP-8.0.0/ For Microsoft Windows: C:\Users\ USER_NAME \EAP-8.0.0\ If you used the JBoss Tools installer to install and configure the JBoss EAP server, the default path for EAP_HOME is USD{user.home}/devstudio/runtimes/jboss-eap : For Red Hat Enterprise Linux: /home/ USER_NAME /devstudio/runtimes/jboss-eap/ For Microsoft Windows: C:\Users\ USER_NAME \devstudio\runtimes\jboss-eap or C:\Documents and Settings\ USER_NAME \devstudio\runtimes\jboss-eap\ Note If you set the Target runtime to 8.0 or a later runtime version in JBoss Tools, your project is compatible with the Jakarta EE 8 specification. Note EAP_HOME is not an environment variable. JBOSS_HOME is the environment variable used in scripts.

Commands:
Chapter 2. Red Hat JBoss Enterprise Application Platform setups You can configure a JBoss EAP instance on single servers that run one or more applications, or you can configure multiple JBoss EAP server instances that are clustered together with an external load balancer for load balancing and failover. 2.1. Simple setup using a single JBoss EAP server instance A simple JBoss EAP setup consists of a single server running one or more deployed applications. Figure 2.1. Simple setup using a single JBoss EAP server instance The JBoss EAP instance uses the datasources subsystem to connect to the following components: A database A Kerberos server JBoss EAP uses the elytron (security) subsystem to connect to the Kerberos server and expose the server to the two deployed applications. JBoss EAP uses the undertow subsystem to handle requests from the client server and send requests to an appropriate application. The application uses the APIs exposed by JBoss EAP to connect to the database and Kerberos server. The application completes its task and the undertow subsystem sends the response back to requester. 2.2. Complex setup using multiple JBoss EAP server instances A complex setup may involve multiple JBoss EAP server instances. For example, you can use a load balancer to distribute the processing load across {JBoss EAP} instances in a managed domain. The following diagram displays three JBoss EAP instances that are arranged by a load balancer in a managed domain: Figure 2.2. Complex setup using multiple JBoss EAP server instances In this example, the administrator configured each instance to use mod_cluster and infinispan session replication to provide high availability (HA) support for applications. Each instance includes the following components: A web application A web service A deployed enterprise bean A database connection that was established with the datasources subsystem A connection with the LDAP server that was established with the elytron (security) subsystem The diagram displays the following configurations associated with a complex JBoss EAP setup: EAP 1 has a messaging-activemq subsystem that is configured with a Jakarta Messaging queue that connects to an external message broker. The external message broker is shared among all running JBoss EAP instances. All inbound requests go through the load balancer. Depending on the configued load-balancing algorithm and the information provided by each JBoss EAP instance, the load balancer directs the requests to the appropriate JBoss EAP instance. Each JBoss EAP instance uses the undertow subsystem to direct the requests to the appropriate application. Each application uses the APIs exposed by JBoss EAP to connect to the database and Kerberos server. After an application performs its work, the undertow subsystem to send a response to the requester. Note The infinispan subsystem propagates non-persisted information, such as session information, among the JBoss EAP instances.

Commands:
probe::vm.kmalloc_node Name probe::vm.kmalloc_node - Fires when kmalloc_node is requested. Synopsis Values ptr Pointer to the kmemory allocated caller_function Name of the caller function. call_site Address of the function caling this kmemory function. gfp_flag_name Type of kmemory to allocate(in string format) name Name of the probe point bytes_req Requested Bytes bytes_alloc Allocated Bytes gfp_flags type of kmemory to allocate

Commands:
vm.kmalloc_node
19.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with Squid. Different types allow you to configure flexible access: httpd_squid_script_exec_t This type is used for utilities such as cachemgr.cgi , which provides a variety of statistics about Squid and its configuration. squid_cache_t Use this type for data that is cached by Squid, as defined by the cache_dir directive in /etc/squid/squid.conf . By default, files created in or copied into the /var/cache/squid/ and /var/spool/squid/ directories are labeled with the squid_cache_t type. Files for the squidGuard URL redirector plug-in for squid created in or copied to the /var/squidGuard/ directory are also labeled with the squid_cache_t type. Squid is only able to use files and directories that are labeled with this type for its cached data. squid_conf_t This type is used for the directories and files that Squid uses for its configuration. Existing files, or those created in or copied to the /etc/squid/ and /usr/share/squid/ directories are labeled with this type, including error messages and icons. squid_exec_t This type is used for the squid binary, /usr/sbin/squid . squid_log_t This type is used for logs. Existing files, or those created in or copied to /var/log/squid/ or /var/log/squidGuard/ must be labeled with this type. squid_initrc_exec_t This type is used for the initialization file required to start squid which is located at /etc/rc.d/init.d/squid . squid_var_run_t This type is used by files in the /var/run/ directory, especially the process id (PID) named /var/run/squid.pid which is created by Squid when it runs.

Commands:
Appendix C. Configuring Ansible inventory location As an option, you can configure inventory location files for the ceph-ansible staging and production environments. Prerequisites An Ansible administration node. Root-level access to the Ansible administration node. The ceph-ansible package is installed on the node. Procedure Navigate to the /usr/share/ceph-ansible directory: Create subdirectories for staging and production: Edit the ansible.cfg file and add the following lines: Create an inventory 'hosts' file for each environment: Open and edit each hosts file and add the Ceph Monitor nodes under the [mons] section: Example Note By default, playbooks run in the staging environment. To run the playbook in the production environment: Additional Resources For more information about installing the ceph-ansible package, see Installing a Red Hat Storage Cluster .

Commands:
cd /usr/share/ceph-ansible
[ansible@admin ceph-ansible]USD mkdir -p inventory/staging inventory/production
[defaults] inventory = ./inventory/staging # Assign a default inventory directory
[ansible@admin ceph-ansible]USD touch inventory/staging/hosts [ansible@admin ceph-ansible]USD touch inventory/production/hosts
[mons] MONITOR_NODE_NAME_1 MONITOR_NODE_NAME_1 MONITOR_NODE_NAME_1
[mons] mon-stage-node1 mon-stage-node2 mon-stage-node3
[ansible@admin ceph-ansible]USD ansible-playbook -i inventory/production playbook.yml
Preface RHTAP empowers teams with its ready-to-use software templates and build pipeline configurations, designed to seamlessly integrate security practices into your development processes. These tools not only alleviate the burden of security considerations for developers but also enhance focus on innovation. Cluster administrators play a pivotal role in tailoring these resources to fit the unique requirements of their on-prem environments, including: Customizing software templates to meet specific organizational needs Modifying build pipeline configurations to align with project goals Configuring GitLab Webhooks for automated pipeline triggers Such customizations streamline development workflows, addressing common concerns around pipelines, vulnerabilities, and policy compliance, thereby letting developers prioritize coding.

Commands:
4.217. papi 4.217.1. RHBA-2011:1755 - papi bug fix and enhancement update An updated papi package that fixes multiple bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. PAPI (Performance Application Programming Interface) is a software library that provides access to the processor's performance-monitoring hardware. The papi package has been upgraded to upstream version 4.1.3, which provides a number of bug fixes and enhancements over the version. (BZ# 705893 ) All PAPI users are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
7.153. parted 7.153.1. RHBA-2015:1357 - parted bug fix update Updated parted packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The parted packages provide tools to create, destroy, resize, move, and copy hard disk partitions. The parted program can be used for creating space for new operating systems, reorganizing disk usage, and copying data to new hard disks. Bug Fixes BZ# 1189328 Partitions that parted created while operating on device-mapper devices, such as mpath, could be smaller than expected. This update modifies parted to convert the native device sector size to 512 sector size when communicating with the device-mapper library. As a result, partitions are created with the correct size in the mentioned situation. BZ# 1180683 Previously, parted did not correctly handle disks or disk images where the backup GUID Partition Table (GPT) header was missing or could not be found at the expected location at the end of the disk. This situation can occur with disks that are shorter or longer than when they were originally created. Consequently, parted could terminate unexpectedly or prompt the user to have parted fix the problem and fail to do so. A patch has been applied to fix GPT backup header handling. Now, after the user instructs parted to fix the problem in the described scenario, parted succeeds. Users of parted are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 86. LRA Since Camel 2.21 The LRA module provides bindings of the Saga EIP with any MicroProfile compatible LRA Coordinator . 86.1. Dependencies When using lra with Red Hat build of Camel Spring Boot make sure to use the following Maven dependency to have support for auto configuration: <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-lra-starter</artifactId> </dependency> 86.2. Spring Boot Auto-Configuration The component supports 5 options, which are listed below. Name Description Default Type camel.lra.coordinator-context-path The context path of the LRA coordinator service. String camel.lra.coordinator-url The base URL of the LRA coordinator service (e.g. ). String camel.lra.enabled Global option to enable/disable component auto-configuration, default is true. true Boolean camel.lra.local-participant-context-path The context path of the local participant callback services. String camel.lra.local-participant-url The local URL where the coordinator should send callbacks to (e.g. ). String

Commands:
<dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-lra-starter</artifactId> </dependency>
5.82. geronimo-specs 5.82.1. RHBA-2012:1397 - geronimo-specs bug fix update Updated geronimo-specs packages that fix one bug are now available for Red Hat Enterprise Linux 6. The geronimo-specs packages provide the specifications for Apache's ASF-licenced J2EE server Geronimo. Bug Fix BZ# 818755 Prior to this update, the geronimo-specs-compat package description contained inaccurate references. This update removes these references so that the description is now accurate. All users of geronimo-specs are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 1. Prerequisites You have created a workbench in OpenShift AI. For more information, see Creating a workbench and selecting an IDE . You have access to an S3-compatible object store. You have the credentials for your S3-compatible object storage account. You have files to work with in your object store. You have configured a connection for your workbench based on the credentials of your S3-compatible storage account. For more information, see Using connections .

Commands:
function::sprint_stack Name function::sprint_stack - Return stack for kernel addresses from string. EXPERIMENTAL! Synopsis Arguments stk String with list of hexadecimal (kernel) addresses. Description Perform a symbolic lookup of the addresses in the given string, which is assumed to be the result of a prior call to backtrace . Returns a simple backtrace from the given hex string. One line per address. Includes the symbol name (or hex address if symbol couldn't be resolved) and module name (if found). Includes the offset from the start of the function if found, otherwise the offset will be added to the module (if found, between brackets). Returns the backtrace as string (each line terminated by a newline character). Note that the returned stack will be truncated to MAXSTRINGLEN, to print fuller and richer stacks use print_stack.

Commands:
function sprint_stack:string(stk:string)
Chapter 27. Red Hat Gluster Storage Red Hat Gluster Storage provides flexible and affordable unstructured data storage for the enterprise. GlusterFS , a key building block of Gluster, is based on a stackable user-space design and aggregates various storage servers over a network and interconnects them into one large parallel network file system. The POSIX-compatible GlusterFS servers, which use the XFS file system format to store data on disks, can be accessed using industry standard access protocols including NFS and CIFS. See the Product Documentation for Red Hat Gluster Storage collection of guides for more information. The glusterfs-server package provides Red Hat Gluster Storage. For detailed information about its installation process, see the Installation Guide for Red Hat Gluster Storage. 27.1. Red Hat Gluster Storage and SELinux When enabled, SELinux serves as an additional security layer by providing flexible mandatory access control for the glusterd (GlusterFS Management Service) and glusterfsd (NFS server) processes as a part of Red Hat Gluster Storage. These processes have advanced process isolation unbounded with the glusterd_t SELinux type.

Commands:
Chapter 2. Accessing hosts Learn how to create a bastion host to access OpenShift Container Platform instances and access the control plane nodes (also known as the master nodes) with secure shell (SSH) access. 2.1. Accessing hosts on Amazon Web Services in an installer-provisioned infrastructure cluster The OpenShift Container Platform installer does not create any public IP addresses for any of the Amazon Elastic Compute Cloud (Amazon EC2) instances that it provisions for your OpenShift Container Platform cluster. To be able to SSH to your OpenShift Container Platform hosts, you must follow this procedure. Procedure Create a security group that allows SSH access into the virtual private cloud (VPC) created by the openshift-install command. Create an Amazon EC2 instance on one of the public subnets the installer created. Associate a public IP address with the Amazon EC2 instance that you created. Unlike with the OpenShift Container Platform installation, you should associate the Amazon EC2 instance you created with an SSH keypair. It does not matter what operating system you choose for this instance, as it will simply serve as an SSH bastion to bridge the internet into your OpenShift Container Platform cluster's VPC. The Amazon Machine Image (AMI) you use does matter. With Red Hat Enterprise Linux CoreOS (RHCOS), for example, you can provide keys via Ignition, like the installer does. Once you provisioned your Amazon EC2 instance and can SSH into it, you must add the SSH key that you associated with your OpenShift Container Platform installation. This key can be different from the key for the bastion instance, but does not have to be. Note Direct SSH access is only recommended for disaster recovery. When the Kubernetes API is responsive, run privileged pods instead. Run oc get nodes , inspect the output, and choose one of the nodes that is a master. The hostname looks similar to ip-10-0-1-163.ec2.internal . From the bastion SSH host you manually deployed into Amazon EC2, SSH into that control plane host (also known as the master host). Ensure that you use the same SSH key you specified during the installation: USD ssh -i <ssh-key-path> core@<master-hostname>

Commands:
ssh -i <ssh-key-path> core@<master-hostname>
Chapter 5. The Migration Toolkit for Runtimes tools You can use the following Migration Toolkit for Runtimes (MTR) tools for assistance in the various stages of your migration and modernization efforts: Web console Migration Toolkit for Runtimes Operator CLI IDE add-ons for the following applications: Eclipse Visual Studio Code, Visual Studio Codespaces, and Eclipse Che IntelliJ IDEA Maven plugin Review the details of each tool to determine which tool is suitable for your project. 5.1. The MTR CLI The CLI is a command-line tool in the Migration Toolkit for Runtimes that you can use to assess and prioritize migration and modernization efforts for applications. It provides numerous reports that highlight the analysis without using the other tools. The CLI includes a wide array of customization options. By using the CLI, you can tune MTR analysis options or integrate with external automation tools. For more information about using the CLI, see CLI Guide . 5.2. The MTR web console By using the web console for the Migration Toolkit for Runtimes, a team of users can assess and prioritize migration and modernization efforts for a large number of applications. You can use the web console to group applications into projects for analysis and provide numerous reports that highlight the results. 5.3. About the MTR plugin for Eclipse The Migration Toolkit for Runtimes (MTR) plugin for Eclipse helps you migrate and modernize applications. The MTR plugin analyzes your projects using customizable rulesets, marks migration issues in the source code, provides guidance to fix the issues, and offers automatic code replacement, or Quick Fixes, if possible. For more information on using the MTR plugin, see the MTR Eclipse Plugin Guide . 5.4. About the MTR extension for Visual Studio Code The Migration Toolkit for Runtimes (MTR) extension for Visual Studio Code helps you migrate and modernize applications. The MTR extension is also compatible with Visual Studio Codespaces, the Microsoft cloud-hosted development environment. The MTR extension analyzes your projects using customizable rulesets, marks issues in the source code, provides guidance to fix the issues, and offers automatic code replacement, if possible. For more information about using the MTR extension, see the MTR Visual Studio Code Extension Guide . 5.5. About the Maven Plugin The Maven plugin for the Migration Toolkit for Runtimes integrates into the Maven build process, allowing developers to continuously evaluate migration and modernization efforts with each iteration of source code. It provides numerous reports that highlight the analysis results, and is designed for developers who want updates with each build.

Commands: