mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Disabling the resource optimization service 4.1. Removing resource optimization files and data Using Ansible to disable the resource optimization service Perform the following steps on each system to disable and uninstall the resource optimization service. Procedure Download the Ansible Playbook with the following command: Run the Ansible Playbook using command: Uninstalling the playbook does not stop or remove the Performance Co-Pilot (PCP) toolkit. Note that PCP may support multiple applications. If you are using PCP exclusively for the resource optimization service, and desire to remove PCP as well, there are a couple options. You can stop and disable the pmlogger and pmcd services, or remove PCP completely by uninstalling the pcp package from the system. Manually disabling the resource optimization service without the use of Ansible The use of Ansible is recommended to expedite the uninstallation process. If you choose to not use Ansible, use the manual procedure that follows: Procedure Disable resource optimization service metrics collection by removing this line from /etc/pcp/pmlogger/control.d/local Restart PCP so that resource optimization service metrics collection is effectively stopped: Remove the resource optimization service configuration file Remove the resource optimization data from the system If you are not using PCP for anything else, you can remove it from your system 4.2. Disabling kernel pressure stall information (PSI) Procedure Edit the /etc/default/grub file and remove psi=1 from the GRUB_CMDLINE_LINUX line. Regenerate the grub configuration file. [user]USD sudo grub2-mkconfig -o /boot/grub2/grub.cfg Reboot the system. Verification step When PSI is disabled, /proc/pressure does not exist.

Commands:
curl -O https://raw.githubusercontent.com/RedHatInsights/ros-backend/v1.0/ansible-playbooks/ros_disable.yml
ansible-playbook -c local ros_disable_and_clean_up.yml
LOCALHOSTNAME n y PCP_LOG_DIR/pmlogger/ros -r -T24h10m -c config.ros -v 100Mb
sudo systemctl pmcd pmlogger
sudo rm /var/lib/pcp/config/pmlogger/config.ros
sudo rm -rf /var/log/pcp/pmlogger/ros
sudo yum remove pcp
[user]USD sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Chapter 1. Architecture of OpenShift AI Red Hat OpenShift AI is a fully Red Hat managed cloud service that is available as an add-on to Red Hat OpenShift Dedicated and to Red Hat OpenShift Service on Amazon Web Services (ROSA Classic). OpenShift AI integrates the following components and services: At the service layer: OpenShift AI dashboard A customer-facing dashboard that shows available and installed applications for the OpenShift AI environment as well as learning resources such as tutorials, quick start examples, and documentation. You can also access administrative functionality from the dashboard, such as user management, cluster settings, accelerator profiles, and notebook image settings. In addition, data scientists can create their own projects from the dashboard. This enables them to organize their data science work into a single project. Model serving Data scientists can deploy trained machine-learning models to serve intelligent applications in production. After deployment, applications can send requests to the model using its deployed API endpoint. Data science pipelines Data scientists can build portable machine learning (ML) workflows with data science pipelines 2.0, using Docker containers. With data science pipelines, data scientists can automate workflows as they develop their data science models. Jupyter (Red Hat managed) A Red Hat managed application that allows data scientists to configure their own notebook server environment and develop machine learning models in JupyterLab. Distributed workloads Data scientists can use multiple nodes in parallel to train machine-learning models or process data more quickly. This approach significantly reduces the task completion time, and enables the use of larger datasets and more complex models. At the management layer: The Red Hat OpenShift AI Operator A meta-operator that deploys and maintains all components and sub-operators that are part of OpenShift AI. Monitoring services Alertmanager, OpenShift Telemetry, and Prometheus work together to gather metrics from OpenShift AI and organize and display those metrics in useful ways for monitoring and billing purposes. Alerts from Alertmanager are sent to PagerDuty, responsible for notifying Red Hat of any issues with your managed cloud service. When you install the Red Hat OpenShift AI Add-on in the Cluster Manager, the following new projects are created: The redhat-ods-operator project contains the Red Hat OpenShift AI Operator. The redhat-ods-applications project installs the dashboard and other required components of OpenShift AI. The redhat-ods-monitoring project contains services for monitoring and billing. The rhods-notebooks project is where notebook environments are deployed by default. You or your data scientists must create additional projects for the applications that will use your machine learning models. Do not install independent software vendor (ISV) applications in namespaces associated with OpenShift AI add-ons unless you are specifically directed to do so on the application tile on the dashboard.

Commands:
4.5.5. Quorum Disk Configuration Clicking on the QDisk tab displays the Quorum Disk Configuration page, which provides an interface for configuring quorum disk parameters if you need to use a quorum disk. Note Quorum disk parameters and heuristics depend on the site environment and the special requirements needed. To understand the use of quorum disk parameters and heuristics, see the qdisk (5) man page. If you require assistance understanding and using quorum disk, contact an authorized Red Hat support representative. The Do Not Use a Quorum Disk parameter is enabled by default. If you need to use a quorum disk, click Use a Quorum Disk , enter the quorum disk parameters, and click Apply . You must restart the cluster for the changes to take effect. Table 4.1, "Quorum-Disk Parameters" describes the quorum disk parameters. Table 4.1. Quorum-Disk Parameters Parameter Description Specify Physical Device: By Device Label Specifies the quorum disk label created by the mkqdisk utility. If this field is used, the quorum daemon reads the /proc/partitions file and checks for qdisk signatures on every block device found, comparing the label against the specified label. This is useful in configurations where the quorum device name differs among nodes. Heuristics Path to Program - The program used to determine if this heuristic is available. This can be anything that can be executed by /bin/sh -c . A return value of 0 indicates success; anything else indicates failure. This field is required. Interval - The frequency (in seconds) at which the heuristic is polled. The default interval for every heuristic is 2 seconds. Score - The weight of this heuristic. The default score for each heuristic is 1. TKO - The number of consecutive failures required before this heuristic is declared unavailable. Minimum Total Score The minimum score for a node to be considered "alive". If omitted or set to 0, the default function, floor(( n +1)/2) , is used, where n is the sum of the heuristics scores. The Minimum Total Score value must never exceed the sum of the heuristic scores; otherwise, the quorum disk cannot be available. Note Clicking Apply on the QDisk Configuration tab propagates changes to the cluster configuration file ( /etc/cluster/cluster.conf ) in each cluster node. However, for the quorum disk to operate or for any modifications you have made to the quorum disk parameters to take effect, you must restart the cluster (see Section 5.4, "Starting, Stopping, Restarting, and Deleting Clusters" ), ensuring that you have restarted the qdiskd daemon on each node.

Commands:
Appendix E. Securing Red Hat Virtualization This information is specific to Red Hat Virtualization. It does not cover fundamental security practices related to any of the following: Disabling unnecessary services Authentication Authorization Accounting Penetration testing and hardening of non-RHV services Encryption of sensitive application data Prerequisites You should be proficient in your organization's security standards and practices. If possible, consult with your organization's Security Officer. Consult the Red Hat Enterprise Linux Security hardening before deploying RHEL hosts. E.1. Applying the DISA STIG profile in RHEL based hosts and the standalone Manager When installing RHV, you can select the DISA STIG profile with the UI installer, which is the profile provided by RHEL 8. Important The DISA STIG profile is not supported for Red Hat Virtualization Host (RHVH). Procedure In the Installation Summary screen, select Security Policy . In the Security Policy screen, set the Apply security policy to On . Select DISA STIG for Red Hat Enterprise Linux 8 . Click Select profile . This action adds a green checkmark to the profile and adds packages to the list of Changes that were done or need to be done . Follow the onscreen instructions if they direct you to make any changes. Click Done . On the Installation Summary screen, verify that the status of Security Policy is Everything okay . Reboot the host. E.1.1. Enabling DISA STIG in a self-hosted engine You can enable DISA STIG in a self-hosted engine during deployment when using the command-line. Procedure Start the self-hosted engine deployment script. See Installing Red Hat Virtualization as a self-hosted engine using the command line . When the deployment script prompts Do you want to apply an OpenSCAP security profile? , enter Yes . When the deployment script prompts Please provide the security profile you would like to use? , enter stig . E.2. Applying the PCI-DSS profile in RHV hosts and the standalone Manager When installing RHVH, you can select the PCI-DSS profile with the UI installer, which is the profile provided by RHEL 8. Procedure In the Installation Summary screen, select Security Policy . In the Security Policy screen, set the Apply security policy to On . Select PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 8 . Click Select profile . This action adds a green checkmark to the profile and adds packages to the list of Changes that were done or need to be done . Follow the onscreen instructions if they direct you to make any changes. Click Done . In the Installation Summary screen, verify that the status of Security Policy is Everything okay . Reboot the host. E.2.1. Enabling PCI-DSS in a self-hosted engine You can enable PCI-DSS in a self-hosted engine during deployment when using the command-line. Procedure Start the self-hosted engine deployment script. See Installing Red Hat Virtualization as a self-hosted engine using the command line . When the deployment script prompts Do you want to apply an OpenSCAP security profile? , enter Yes . When the deployment script prompts Please provide the security profile you would like to use? , enter pci-dss .

Commands:
Appendix B. Revision history 0.0-9 Tue March 18 2025, Gabriela Fialova ( gfialova@redhat.com ) Added a Known Issue in RHEL-82566 (Installer) 0.0-8 Tue March 11 2025, Gabriela Fialova ( gfialova@redhat.com ) Updated a Deprecated functionality in RHEL-30730 (Filesystems and storage) 0.0-7 Thu March 6 2025, Gabriela Fialova ( gfialova@redhat.com ) Updated a Technology Preview in RHELPLAN-145900 (IdM) 0.0-6 Thu February 27 2025, Marc Muehlfeld ( mmuehlfeld@redhat.com ) Added a Technology Preview in RHELDOCS-19773 (Networking) Added a Deprecated Functionality in RHELDOCS-19774 (Networking) Removed an enhancement about composefs, as it remains a Technology Preview (Containers) 0.0-5 Mon February 24 2025, Gabriela Fialova ( gfialova@redhat.com ) Added a Known Issue in RHELDOCS-19626 (Security) Updated a Feature in RHELDOCS-18125 (RHEL in cloud environments) 0.0-4 Wed February 19 2025, Gabriela Fialova ( gfialova@redhat.com ) Added a New Feature in RHELDOCS-18391 (Infrastructure services) 0.0-6 Thu Feb 06 2025, Gabriela Fialova ( gfialova@redhat.com ) Added an Enhancement RHELDOCS-18451 (Filesystems) 0.0-5 Thu Jan 30 2025, Gabriela Fialova ( gfialova@redhat.com ) Added an Known Issue RHELDOCS-19603 (IdM SSSD) 0.0-4 Wed Jan 22 2025, Gabriela Fialova ( gfialova@redhat.com ) Updated links in a Technology Preview RHELDOCS-19061 (IdM DS) Added an Known Issue RHELDOCS-18863 (Virtualization) Updated an Enhancement RHEL-45620 (Security) Corrected typos throughout the document. 0.0-3 Mon Jan 20 2025, Gabriela Fialova ( gfialova@redhat.com ) Added an Known Issue RHEL-13837 (Installer) 0.0-2 Thu January 16 2025, Marc Muehlfeld ( mmuehlfeld@redhat.com ), Gabriela Fialova ( gfialova@redhat.com ) Added a Bug Fix RHEL-73167 (Networking) Added a Removed Functionality RHELDOCS-19141 (Desktop) Added a Removed Functionality RHELDOCS-19156 (Desktop) 0.0-1 Thu January 9 2025, Gabriela Fialova ( gfialova@redhat.com ) Updated an Enhancement RHEL-7768 (Filesystems and storage) 0.0-0 Wed November 13 2024, Gabriela Fialova ( gfialova@redhat.com ) Release of the Red Hat Enterprise Linux 9.5 Release Notes.

Commands:
2.4. Security KVM virtual machines use the following features to improve their security: SELinux Security-Enhanced Linux, or SELinux, provides Mandatory Access Control (MAC) for all Linux systems, and thus benefits also Linux guests. Under the control of SELinux, all processes and files are given a type , and their access on the system is limited by fine-grained controls of various types. SELinux limits the abilities of an attacker and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. sVirt sVirt is a technology included in Red Hat Enterprise Linux 7 that integrates SELinux and virtualization. It applies Mandatory Access Control (MAC) to improve security when using virtual machines, and hardens the system against hypervisor bugs that might be used to attack the host or another virtual machine. Note For more information on security in virtualization, see the Red Hat Enterprise Linux 7 Virtualization Security Guide .

Commands:
Chapter 5. Testing the configured back ends After you deploy the back ends to the overcloud, test that you can successfully create volumes on them. Procedure Run the following command as the stack user to load the environment variables defined in home/stack/overcloudrec : Note For more information, see Accessing the overcloud in the Director Installation and Usage guide. Create a volume type for each back end. Log in to the Controller node of the overcloud as the stack user and run the following command: These commands create the volume types backend1 and backend2 , one for each back end that is defined with the cinder::config::cinder_config class of the environment file that you created. Map each volume type to the volume_backend_name of a back end that is enabled with the cinder_user_enabled_backends class of the environment file that you created The following commands map the volume type backend1 to netapp1 and backend2 to netapp2 : Run the following command to test that it is possible to create a back end on netapp1 by invoking the backend1 volume type: Create a similar volume on the netapp2 back end by invoking the backend2 volume type:

Commands:
source /home/stack/overcloudrc
cinder type-create backend1 cinder type-create backend2
cinder type-key backend1 set volume_backend_name=netapp1 cinder type-key backend2 set volume_backend_name=netapp2
cinder create --volume-type backend1 --display_name netappvolume_1 1
cinder create --volume-type backend2 --display_name netappvolume_2 1
Providing feedback on JBoss EAP documentation To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account. Procedure Click the following link to create a ticket . Please include the Document URL , the section number and describe the issue . Enter a brief description of the issue in the Summary . Provide a detailed description of the issue or enhancement in the Description . Include a URL to where the issue occurs in the documentation. Clicking Submit creates and routes the issue to the appropriate documentation team.

Commands:
E.5. Additional Resources Below are additional sources of information about the proc file system. Installable Documentation /usr/share/doc/kernel-doc- kernel_version /Documentation/ - This directory, which is provided by the kernel-doc package, contains documentation about the proc file system. Before accessing the kernel documentation, you must run the following command as root: /usr/share/doc/kernel-doc- kernel_version /Documentation/filesystems/proc.txt - Contains assorted, but limited, information about all aspects of the /proc/ directory. /usr/share/doc/kernel-doc- kernel_version /Documentation/sysrq.txt - An overview of System Request Key options. /usr/share/doc/kernel-doc- kernel_version /Documentation/sysctl/ - A directory containing a variety of sysctl tips, including modifying values that concern the kernel ( kernel.txt ), accessing file systems ( fs.txt ), and virtual memory use ( vm.txt ). /usr/share/doc/kernel-doc- kernel_version /Documentation/networking/ip-sysctl.txt - A detailed overview of IP networking options.

Commands:
~]# yum install kernel-doc
4.8.2. Modifying a Failover Domain To modify a failover domain, follow the steps in this section. From the cluster-specific page, you can configure Failover Domains for that cluster by clicking on Failover Domains along the top of the cluster display. This displays the failover domains that have been configured for this cluster. Click on the name of a failover domain. This displays the configuration page for that failover domain. To modify the Prioritized , Restricted , or No Failback properties for the failover domain, click or unclick the check box to the property and click Update Properties . To modify the failover domain membership, click or unclick the check box to the cluster member. If the failover domain is prioritized, you can also modify the priority setting for the cluster member. Click Update Settings .

Commands:
21.9. Live Migration Errors There may be cases where a live migration causes the memory contents to be re-transferred over and over again. This process causes the guest to be in a state where it is constantly writing to memory and therefore will slow down migration. If this should occur, and the guest is writing more than several tens of MBs per second, then live migration may fail to finish (converge). This issue is not scheduled to be resolved at the moment for Red Hat Enterprise Linux 6, and is scheduled to be fixed in Red Hat Enterprise Linux 7. The current live-migration implementation has a default migration time configured to 30ms. This value determines the guest pause time at the end of the migration in order to transfer the leftovers. Higher values increase the odds that live migration will converge

Commands:
Chapter 29. Deploying and testing the IT order case project After you create and define all components of the new IT_Orders_New case project, deploy and test the new project. Prerequisites You have a running KIE Server instance connected to Business Central. For more information see Installing and configuring Red Hat Process Automation Manager on Red Hat JBoss EAP 7.4 . You have created a new case in Business Central. For more information, see Chapter 25, Creating a new IT_Orders case project . You have created the data objects. For more information, see Chapter 26, Data objects . You have created the Place order sub-process. For more information, see Section 27.1, "Creating the Place order sub-process" . You have designed the orderhardware case definition. For more information, see Chapter 27, Designing the case definition . Procedure In Business Central, go to Menu Design Projects and click IT_Orders_New . Click Deploy . Go to Menu Manage Process Definitions Manage Process Instances New Process Instance . Go to Menu Deploy and click Execution Servers and verify that a new container is deployed and started. Use the Case Management Showcase application to start a new case instance. For instructions about using the Showcase application, see Using the Showcase application for case management .

Commands:
probe::nfs.aop.set_page_dirty Name probe::nfs.aop.set_page_dirty - NFS client marking page as dirty Synopsis nfs.aop.set_page_dirty Values __page the address of page page_flag page flags Description This probe attaches to the generic __set_page_dirty_nobuffers function. Thus, this probe is going to fire on many other file systems in addition to the NFS client.

Commands:
Chapter 56. Compiler and Tools Memory consumption of applications using libcurl grows with each TLS connection The Network Security Services (NSS) PK11_DestroyGenericObject() function does not release resources allocated by PK11_CreateGenericObject() early enough. Consequently, the memory allocated by applications using the libcurl package can grow with each TLS connection. To work around this problem: Re-use existing TLS connections where possible or Use certificates and keys from the NSS database instead of loading them from files directly using libcurl (BZ# 1510247 ) OProfile and perf can not sample events on 2nd generation Intel Xeon Phi processors when NMI watchdog is disabled Due to a performance counter hardware error, sampling performance events with the default hardware event CPU_CLK_UNHALTED may fail on 2nd generation Intel Xeon Phi processors. As a consequence, the OProfile and perf tools fail to receive any samples when the NMI watchdog is disabled. To work around this problem, enable NMI watchdog before running the perf or operf command: Note that this workaround allows only the selected tool to work correctly, but not the NMI watchdog, because it is based on the NMI watchdog using the erroneous counter. (BZ#1536004) ksh with the KEYBD trap mishandles multibyte characters The Korn Shell (KSH) is unable to correctly handle multibyte characters when the KEYBD trap is enabled. Consequently, when the user enters, for example, Japanese characters, ksh displays an incorrect string. To work around this problem, disable the KEYBD trap in the /etc/kshrc file by commenting out the following line: For more details, see a related Knowledgebase solution . (BZ# 1503922 )

Commands:
echo 1 > /proc/sys/kernel/nmi_watchdog operf some_examined_program opreport
trap keybd_trap KEYBD
Chapter 15. Deleting applications You can delete applications created in your project. 15.1. Deleting applications using the Developer perspective You can delete an application and all of its associated components using the Topology view in the Developer perspective: Click the application you want to delete to see the side panel with the resource details of the application. Click the Actions drop-down menu displayed on the upper right of the panel, and select Delete Application to see a confirmation dialog box. Enter the name of the application and click Delete to delete it. You can also right-click the application you want to delete and click Delete Application to delete it.

Commands: