mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 55. Hardware Enablement Platforms relying on DDF-based RAID are not supported Disk Data Format (DDF)-based BIOS RAID is currently not supported in Red Hat Enterprise Linux. This includes systems using the LSI BIOS, which require the megasr proprietary driver. However, on certain systems, such as IBM z Systems servers with the ServeRAID adapter, it is possible to disable RAID in the BIOS. To do this, enter the UEFI menu and navigate through the System Settings and Devices and I/O Ports menus to the Configure the onboard SCU submenu. Then change the SCU setting from RAID to nonRAID . Save your changes and reboot the system. In this mode, the storage is configured using an open-source non-RAID LSI driver available in Red Hat Enterprise Linux, such as mptsas , mpt2sas , or mpt3sas . To obtain the megasr driver for IBM systems refer to the IBM support page: http://www-947.ibm.com/support/entry/portal/support Note that the described restriction does not apply to LSI adapters that use the megaraid driver, as such adapters implement RAID functions in firmware. (BZ#1067292)

Commands:
2.3. SELinux Contexts for Users Use the following command to view the SELinux context associated with your Linux user: In Red Hat Enterprise Linux, Linux users run unconfined by default. This SELinux context shows that the Linux user is mapped to the SELinux unconfined_u user, running as the unconfined_r role, and is running in the unconfined_t domain. s0-s0 is an MLS range, which in this case, is the same as just s0 . The categories the user has access to is defined by c0.c1023 , which is all categories ( c0 through to c1023 ).

Commands:
~]USD id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Chapter 3. Accessing hosts Learn how to create a bastion host to access OpenShift Container Platform instances and access the control plane nodes with secure shell (SSH) access. 3.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. After 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. 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 1. Disaster Recovery Solutions Red Hat Virtualization (RHV) supports two types of disaster recovery solutions to ensure that environments can recover when a site outage occurs. Both solutions support two sites, and both require replicated storage. Active-Active Disaster Recovery : This solution is implemented using a stretch cluster configuration. This means that there is a single RHV environment with a cluster that contains hosts capable of running the required virtual machines in the primary and secondary site. Virtual machines automatically migrate to hosts in the secondary site if an outage occurs. However, the environment must meet latency and networking requirements. See Section 2.1, "Active-Active Overview" for more information. Active-Passive Disaster Recovery : Also referred to as site-to-site failover, this disaster recovery solution is implemented by configuring two seperate RHV environments: the active primary environment, and the passive secondary (backup) environment. Failover and failback between sites must be manually executed, and is managed by Ansible. See Section 3.1, "Active-Passive Overview" for more information.

Commands:
B.2. Continuing Lines in LDIF In LDIF files, a line can be broken and continued (called folded ) by indenting the continued portion of the line by exactly one space. For example, the following two statements are identical: It is not required to break and continue LDIF lines. However, doing so may improve the readability of the LDIF file. The usual convention is that an LDIF file does not contain more than 78 columns of text.

Commands:
dn: cn=some_example_user,dc=example,dc=com dn: cn=some_e xample_user, dc=example,d c=com
3.3.2. Adding a New Group If there is a new group you need to add to the system, follow this procedure: Select Add Group from the User Manager toolbar: Figure 3.4. New Group Type the name of the new group. Specify the group ID (GID) for the new group by checking the Specify group ID manually check box. Select the GID. Note that Red Hat Enterprise Linux also reserves group IDs lower than 500 for system groups. Click OK to create the group. The new group appears in the group list.

Commands:
Chapter 7. Accessing the dashboard After you have installed OpenShift AI and added users, you can access the URL for your OpenShift AI console and share the URL with the users to let them log in and work on their models. Prerequisites You have installed OpenShift AI on your OpenShift cluster. You have added at least one user to the user group for OpenShift AI. Procedure Log in to OpenShift web console. Click the application launcher ( ). Right-click on Red Hat OpenShift AI and copy the URL for your OpenShift AI instance. Provide this instance URL to your data scientists to let them log in to OpenShift AI. Verification Confirm that you and your users can log in to OpenShift AI by using the instance URL. Additional resources Logging in to OpenShift AI Adding users to OpenShift AI user groups .

Commands:
5.95. graphviz 5.95.1. RHBA-2012:1291 - graphviz bug fix update Updated graphviz packages that fix three bugs are now available for Red Hat Enterprise Linux 6. Graphviz is open-source graph-visualization software. Graph visualization is a way of representing structural information as diagrams of abstract graphs and networks. It has important applications in networking, bioinformatics, software engineering, database and web design, machine learning, and in visual interfaces for other technical domains. Bug Fixes BZ# 772637 Previously, the dot tool could generate different images on 32-bit and 64-bit architectures, which could consequently lead to multilib conflicts of packages that use graphviz during its build process. The problem was caused by different instructions used for floating points processing. On 32-bit Intel architecture, the code is now compiled with the "--ffloat-store" compiler flag, which ensures that identical images are generated regardless of the used architecture. BZ# 821920 The graphviz-tcl package included the "demo" directory, which contained examples in various languages. This caused implicit dependencies to be introduced. With this update, all examples are installed as documentation, which reduces the number of implicit dependencies. BZ# 849134 The "dot -c" command which is run in the %postun scriptlet recreates graphviz configuration files to be up-to-date with the current state of the installed plug-ins. Previously, if the command failed to load plug-ins specified in the configuration files, warning messages were printed when removing the graphviz-gd package. These messages could have been confusing, and have been therefore removed. All users of graphviz are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 7. Enabling the Connectivity Link dynamic plug-in in OpenShift The Connectivity Link Operator automatically installs and configures the Connectivity Link dynamic plug-in for the OpenShift web console. You can use the Connectivity Link dynamic plug-in to view and manage your Gateways and policies in the OpenShift web console. Note You must perform these steps on each OpenShift cluster that you want to use the Connectivity Link dynamic plug-in. Prerequisites See Chapter 1, Connectivity Link prerequisites and permissions . You have access to the OpenShift Container Platform web console. Procedure In the OpenShift Container Platform web console, log in with cluster-admin privileges. In the left navigation menu, select the Administrator perspective. Click Home > Overview . In the Status panel, click Dynamic Plugins > View all . On the Console plugins tab, find the kuadrant-console-plugin entry in the table, which should be listed but disabled. In the kuadrant-console-plugin row, click Disabled . Select the Enable option, and click Save . Wait for the plug-in status to change to Loaded . Verification When the plug-in is enabled, refresh the console. You will see a new Connectivity Link menu item in the navigation sidebar. You can click Connectivity Link > Overview to explore the available resources and to get started with creating a Gateway and configuring policies in the OpenShift web console. steps For examples of Gateway and policy configuration, see Configuring and deploying Gateway policies with Connectivity Link .

Commands:
Chapter 1. Overview Due to the growing demands on availability, one copy of data is not enough. To ensure business continuity, a reliable and highly available architecture must replicate data across more than just one replication site. Using multitarget system replication, the primary site can replicate data changes to more than one secondary site. For more information, see SAP HANA Multitarget System Replication . This document describes how to configure an additional replication site for disaster recovery using SAP HANA Multitarget System Replication on a 2-node cluster, installed as described in Automating SAP HANA Scale-Up System Replication using the RHEL HA Add-On . A sample configuration looks like this: The initial setup is as follows: Replicate Primary site 1 (DC1) to Secondary site 2 (DC2) Replicate Primary site 1 (DC1) to Secondary site 3 (DC3) If the primary site fails, the primary site switches to secondary site 2 (DC2) and the former primary site 1 (DC1) will become a secondary site. When failover occurs, this solution ensures that the configured primary site is switched at the third site as well. The configuration after failover is as follows: Primary running on DC2 Secondary running on DC1 (synced from DC2) Secondary running on DC3 (synced from DC2) The SAP HANA instance on remotehost3 will be automatically re-registered to the new primary as long as this instance is up and running during the failover. This document also describes the example of switching the primary database to the third site. Please note that further network configuration is required for the connection of the clients to the database. This is not within the scope of this document. For further information, please check the following: SAP HANA Administration Guide for SAP HANA Platform How to Setup SAP HANA Multi-Target System Replication

Commands:
13.8. Migrating Directories from Earlier Releases With Red Hat Enterprise Linux, OpenLDAP uses Sleepycat Software's Berkeley DB system as its on-disk storage format for directories. Earlier versions of OpenLDAP used GNU Database Manager ( gdbm ). For this reason, before upgrading an LDAP implementation to Red Hat Enterprise Linux 4.5.0, original LDAP data should first be exported before the upgrade, and then reimported afterwards. This can be achieved by performing the following steps: Before upgrading the operating system, run the command /usr/sbin/slapcat -l ldif-output . This outputs an LDIF file called ldif-output containing the entries from the LDAP directory. Upgrade the operating system, being careful not to reformat the partition containing the LDIF file. Re-import the LDAP directory to the upgraded Berkeley DB format by executing the command /usr/sbin/slapadd -l ldif-output .

Commands:
7.190. procps 7.190.1. RHBA-2012:1463 - procps bug fix update Updated procps packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The procps packages provide a set of system utilities to provide system information using the /proc file system. The procps package includes the free, pgrep, pkill, pmap, ps, pwdx, skill, slabtop, snice, sysctl, tload, top, uptime, vmstat, w, and watch utilities. Bug Fixes BZ#851664 Prior to this update, the 'si' and 'so' values were always zero for "m" or "M" units. This was caused by an arithmetic precision loss in the expressions used for the calculations. This update modifies the expressions to avoid precision losses. BZ# 875077 Prior to this update, the vmstat tool could be terminated unexpectedly raising the SIGFPE exception when the total sum of 'us', 'sy', 'id', 'wa' and 'st' values returned by the kernel was zero. This situation could only appear on certain specific platforms. this update modifies the internal evaluation so that the vmstat tool is more robust and does no longer terminate. All users of procps are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 10. Tuning the WSGI processes If you are seeing request failures due to long-running API processes, those API processes can benefit from tuning. By default, IPA allocates 4 Web Server Gateway Interface (WSGI) processes for the API service on 64-bit systems. This default limitation to 4 processes is implemented for memory conservation purposes. Increasing the number of the WSGI processes allows more requests to be accepted at the expense of higher CPU use and memory consumption. By default, IPA uses approximately 100 to 110MB of resident memory for the API per WSGI process. With tuning this to 16 processes, which is the recommended limit, the amount is approximately 1.3GB. Procedure Modify the processes value in the /etc/httpd/conf.d/ipa.conf file: Any of the longer-running API endpoints can benefit from tuning. This tuning decision is for the user to make. For example, an OpenStack installation consists of several controllers containing multiple services. Each service requests a certificate so that all internal communication occurs over Transport Layer Security (TLS). When installing or refreshing a controller or compute node, these certificates can be requested or refreshed. In scenarios involving multiple controllers or compute nodes, the volume of certificate requests can become considerable. These requests are automated, so they happen at or nearly at the same time. Increasing the number of the WSGI threads allows the installation to complete. 10.1. Optimizing CPU usage for improved IPA server performance When encountering performance limitations during high-volume certificate issuance tasks, tuning the CPU and Web Server Gateway Interface (WSGI) process counts can significantly enhance an IPA server's capability to handle simultaneous requests. With a server configured with 4 CPUs and 70 clients requesting 7 certificates each (490 certificates in total), server timeouts occured as the request volume exceeded the server's processing capacity. Increasing the CPU count to 8 and matching the WSGI process count to 8 raised the certificate handling capacity to 630 certificates, a 28% increase over the 4 CPU configuration, despite a 100% increase in CPU count. Further increasing the CPU count to 16 showed no additional performance gains with only 8 WSGI processes. However, by increasing the WSGI process count to 16, the server processed 770 certificates with 110 clients, reflecting a 22% improvement over the 8 CPU setup. On average, doubling the number of CPUs resulted in a 25% increase in certificate issuance capacity, as long as the WSGI processes were tuned accordingly. This emphasizes the need to scale both CPU and WSGI processes together to prevent bottlenecks and optimize server performance.

Commands:
WSGIDaemonProcess ipa processes= <4> threads=1 maximum-requests=500 \
Chapter 5. OpenShift Data Foundation upgrade overview As an operator bundle managed by the Operator Lifecycle Manager (OLM), OpenShift Data Foundation leverages its operators to perform high-level tasks of installing and upgrading the product through ClusterServiceVersion (CSV) CRs. 5.1. Upgrade Workflows OpenShift Data Foundation recognizes two types of upgrades: Z-stream release upgrades and Minor Version release upgrades. While the user interface workflows for these two upgrade paths are not quite the same, the resulting behaviors are fairly similar. The distinctions are as follows: For Z-stream releases, OCS will publish a new bundle in the redhat-operators CatalogSource . The OLM will detect this and create an InstallPlan for the new CSV to replace the existing CSV. The Subscription approval strategy, whether Automatic or Manual, will determine whether the OLM proceeds with reconciliation or waits for administrator approval. For Minor Version releases, OpenShift Container Storage will also publish a new bundle in the redhat-operators CatalogSource . The difference is that this bundle will be part of a new channel, and channel upgrades are not automatic. The administrator must explicitly select the new release channel. Once this is done, the OLM will detect this and create an InstallPlan for the new CSV to replace the existing CSV. Since the channel switch is a manual operation, OLM will automatically start the reconciliation. From this point onwards, the upgrade processes are identical. 5.2. ClusterServiceVersion Reconciliation When the OLM detects an approved InstallPlan , it begins the process of reconciling the CSVs. Broadly, it does this by updating the operator resources based on the new spec, verifying the new CSV installs correctly, then deleting the old CSV. The upgrade process will push updates to the operator Deployments, which will trigger the restart of the operator Pods using the images specified in the new CSV. Note While it is possible to make changes to a given CSV and have those changes propagate to the relevant resource, when upgrading to a new CSV all custom changes will be lost, as the new CSV will be created based on its unaltered spec. 5.3. Operator Reconciliation At this point, the reconciliation of the OpenShift Data Foundation operands proceeds as defined in the OpenShift Data Foundation installation overview . The operators will ensure that all relevant resources exist in their expected configurations as specified in the user-facing resources (for example, StorageCluster ).

Commands:
24.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 DHCP: dhcp_etc_t This type is mainly used for files in the /etc directory, including configuration files. dhcpd_var_run_t This type is used for the PID file for dhcpd , in the /var/run/ directory. dhcpd_exec_t This type is used for transition of DHCP executable files to the dhcpd_t domain. dhcpd_initrc_exec_t This type is used for transition of DHCP executable files to the dhcpd_initrc_t domain. Note To see the full list of files and their types for dhcpd , enter the following command:

Commands:
~]USD grep dhcp /etc/selinux/targeted/contexts/files/file_contexts
15.5. Reinstalling an Existing Host as a Self-Hosted Engine Node You can convert an existing, standard host in a self-hosted engine environment to a self-hosted engine node capable of hosting the Manager virtual machine. Procedure Click Compute Hosts and select the host. Click Management Maintenance and click OK . Click Installation Reinstall . Click the Hosted Engine tab and select DEPLOY from the drop-down list. Click OK . The host is reinstalled with self-hosted engine configuration, and is flagged with a crown icon in the Administration Portal.

Commands:
12.2. Other Resources Fedora Main page: http://fedoraproject.org/wiki/SELinux . Troubleshooting: http://fedoraproject.org/wiki/SELinux/Troubleshooting . Fedora SELinux FAQ: https://fedoraproject.org/wiki/SELinux_FAQ . The National Security Agency (NSA) NSA was the original developer of SELinux. Researchers in NSA's National Information Assurance Research Laboratory (NIARL) designed and implemented flexible mandatory access controls in the major subsystems of the Linux kernel and implemented the new operating system components provided by the Flask architecture, namely the security server and the access vector cache. Tresys Technology Tresys Technology are the upstream for: SELinux Project Wiki . SELinux Reference Policy . The SELinux GitHub repositories SELinux Project: https://github.com/SELinuxProject Tresys Technology: https://github.com/TresysTechnology/ SELinux Project Wiki Main page: http://selinuxproject.org/page/Main_Page . User resources, including links to documentation, mailing lists, websites, and tools: http://selinuxproject.org/page/User_Resources . The SELinux Notebook - The Foundations - 4th Edition http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf DigitalOcean: An Introduction to SELinux on CentOS 7 https://www.digitalocean.com/community/tutorial_series/an-introduction-to-selinux-on-centos-7 IRC On Freenode : #selinux #fedora-selinux

Commands:
Chapter 3. Migrating to IdM on RHEL 8 from FreeIPA on non-RHEL Linux distributions To migrate a FreeIPA deployment on a non-RHEL Linux distribution to an Identity Management (IdM) deployment on RHEL 8 servers, you must first add a new RHEL 8 IdM Certificate Authority (CA) replica to your existing FreeIPA environment, transfer certificate-related roles to it, and then retire the non-RHEL FreeIPA servers. Warning Performing an in-place conversion of a non-RHEL FreeIPA server to a RHEL 8 IdM server using the Convert2RHEL tool is not supported. To perform the migration, follow the same procedure as Migrating your IdM environment from RHEL 7 servers to RHEL 8 servers , with your non-RHEL FreeIPA CA replica acting as the RHEL 7 server: Configure a RHEL 8 server and add it as an IdM replica to your current FreeIPA environment on the non-RHEL Linux distribution. For details, see Installing the RHEL 8 Replica . Make the RHEL 8 replica the certificate authority (CA) renewal server. For details, see Assigning the CA renewal server role to the RHEL 8 IdM server . Stop generating the certificate revocation list (CRL) on the non-RHEL server and redirect CRL requests to the RHEL 8 replica. For details, see Stopping CRL generation on a RHEL 7 IdM CA server . Start generating the CRL on the RHEL 8 server. For details, see Starting CRL generation on the new RHEL 8 IdM CA server . Stop and decommission the original non-RHEL FreeIPA CA renewal server. For details, see Stopping and decommissioning the RHEL 7 server . Additional resources Migrating your IdM environment from RHEL 7 servers to RHEL 8 servers

Commands: