mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Overview of distributed workloads You can use the distributed workloads feature to queue, scale, and manage the resources required to run data science workloads across multiple nodes in an OpenShift cluster simultaneously. Typically, data science workloads include several types of artificial intelligence (AI) workloads, including machine learning (ML) and Python workloads. Distributed workloads provide the following benefits: You can iterate faster and experiment more frequently because of the reduced processing time. You can use larger datasets, which can lead to more accurate models. You can use complex models that could not be trained on a single node. You can submit distributed workloads at any time, and the system then schedules the distributed workload when the required resources are available. The distributed workloads infrastructure includes the following components: CodeFlare Operator Secures deployed Ray clusters and grants access to their URLs CodeFlare SDK Defines and controls the remote distributed compute jobs and infrastructure for any Python-based environment Note The CodeFlare SDK is not installed as part of OpenShift AI, but it is contained in some of the notebook images provided by OpenShift AI. KubeRay Manages remote Ray clusters on OpenShift for running distributed compute workloads Kueue Manages quotas and how distributed workloads consume them, and manages the queueing of distributed workloads with respect to quotas Note You must disable the API Priority and Fairness configuration for the Visibility API, as described in the Enabling/Disabling API Priority and Fairness section in the Kueue Cluster Administration guide. You can run distributed workloads from data science pipelines, from Jupyter notebooks, or from Microsoft Visual Studio Code files. Note Data science pipelines workloads are not managed by the distributed workloads feature, and are not included in the distributed workloads metrics.

Commands:
Chapter 1. Supported conversion paths Important Red Hat recommends that you seek the support of Red Hat Consulting services to ensure that the conversion process is smooth. Currently, it is possible to convert your systems from the following Linux distributions and versions to the corresponding minor version of RHEL listed in Table 1.1. Table 1.1. Supported conversion paths Source OS Source version Target OS and version Product Variant Available Conversion Methods Alma Linux 9.5 RHEL 9.5 N/A Command-line interface, Satellite 8.10 RHEL 8.10 N/A Command-line interface, Satellite 8.8 RHEL 8.8 EUS N/A Command-line interface, Satellite CentOS Linux 8.5 RHEL 8.5 N/A Command-line interface, Satellite 7.9 RHEL 7.9 Server Command-line interface, Satellite, Red Hat Insights Oracle Linux 9.5 RHEL 9.5 N/A Command-line interface, Satellite 8.10 RHEL 8.10 N/A Command-line interface, Satellite 7.9 RHEL 7.9 Server Command-line interface, Satellite Rocky Linux 9.5 RHEL 9.5 N/A Command-line interface, Satellite 8.10 RHEL 8.10 N/A Command-line interface, Satellite 8.8 RHEL 8.8 EUS N/A Command-line interface, Satellite Because the last available minor version of CentOS Linux is CentOS Linux 8.5, it is not possible to convert from CentOS Linux 8 directly to the latest available minor version of RHEL 8. It is recommended to update your system to the latest version of RHEL after the conversion. RHEL 7 reaches the end of the Maintenance Support Phase on June 30, 2024. If you are converting to RHEL 7 and plan to stay on RHEL 7, it is strongly recommended to purchase the Extended Life Cycle Support (ELS) add-on subscription. If you plan to convert to RHEL 7 and then immediately upgrade to RHEL 8 or later, an ELS subscription is not needed. Note that without ELS, you have limited support for RHEL 7, including for the upgrade from RHEL 7 to RHEL 8. For more information, see the Red Hat Enterprise Linux Life Cycle and the Convert2RHEL Support Policy . In addition to the above supported conversion paths, it is also possible to perform an unsupported conversion from Scientific Linux 7, CentOS Stream 8, and CentOS Stream 9 to RHEL. For information about unsupported conversions, see How to perform an unsupported conversion from a RHEL-derived Linux distribution to RHEL . For information about Red Hat's support policy for Linux distribution conversions, see Convert2RHEL Support Policy .

Commands:
13.4. Specifying the Location of a Driver Update Image File or a Driver Update Disk If the installer detects more than one possible device that could hold a driver update, it prompts you to select the correct device. If you are not sure which option represents the device on which the driver update is stored, try the various options in order until you find the correct one. Figure 13.7. Selecting a driver disk source If the device that you choose contains no suitable update media, the installer will prompt you to make another choice. If you made a driver update disk on CD, DVD, or USB flash drive, the installer now loads the driver update. However, if the device that you selected is a type of device that could contain more than one partition (whether the device currently has more than one partition or not), the installer might prompt you to select the partition that holds the driver update. Figure 13.8. Selecting a driver disk partition The installer prompts you to specify which file contains the driver update: Figure 13.9. Selecting an ISO image Expect to see these screens if you stored the driver update on an internal hard drive or on a USB storage device. You should not see them if the driver update is on a CD or DVD. Regardless of whether you are providing a driver update in the form of an image file or with a driver update disk, the installer now copies the appropriate update files into a temporary storage area (located in system RAM and not on disk). The installer might ask whether you would like to use additional driver updates. If you select Yes , you can load additional updates in turn. When you have no further driver updates to load, select No . If you stored the driver update on removable media, you can now safely eject or disconnect the disk or device. The installer no longer requires the driver update, and you can re-use the media for other purposes.

Commands:
Appendix C. Using Your Subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ Streams entries in the JBOSS INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2022-02-01 16:35:35 UTC

Commands:
8.173. readahead 8.173.1. RHBA-2013:1739 - readahead bug fix update Updated readahead packages that fix one bug are now available for Red Hat Enterprise Linux 6. The readahead packages provide an utility that reads the contents of a list of files into memory. The files are read from the cache directory when they are actually needed. Its goal is to speed up the boot process. Bug Fix BZ# 1017072 The readahead-collect tool of the readahead package delayed the startup process of the auditd daemon on system boot. This could have caused various problems with auditing, kdump and runlevel switching. To speed up the boot process, readhead is now turned off by default. If needed, readhead can be turned on by editing the /etc/sysconfig/readahead file. Users of readahead are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 6. Confining Users In Red Hat Enterprise Linux, users are mapped to the SELinux unconfined_u user by default. All processes run by unconfined_u are in the unconfined_t domain. This means that users can access across the system within the limits of the standard Linux DAC policy. However, a number of confined SELinux users are available in Red Hat Enterprise Linux. This means that users can be restricted to limited set of capabilities. Each Linux user is mapped to an SELinux user using SELinux policy, allowing Linux users to inherit the restrictions placed on SELinux users, for example (depending on the user), not being able to: run the X Window System use networking run setuid applications (unless SELinux policy permits it) or run the su and sudo commands. For example, processes run by the SELinux user_u user are in the user_t domain. Such processes can connect to network, but cannot run the su or sudo commands. This helps protect the system from the user. See Section 3.3, "Confined and Unconfined Users" , Table 3.1, "SELinux User Capabilities" for further information about confined users and their capabilities. 6.1. Linux and SELinux User Mappings As root, enter the following command to view the mapping between Linux users and SELinux users: In Red Hat Enterprise Linux, Linux users are mapped to the SELinux __default__ login by default (which is in turn mapped to the SELinux unconfined_u user). When a Linux user is created with the useradd command, if no options are specified, they are mapped to the SELinux unconfined_u user. The following defines the default-mapping:

Commands:
~]# semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 *
__default__ unconfined_u s0-s0:c0.c1023 *
Chapter 5. Known issues This section lists known issues with Red Hat Developer Hub 1.2: Deprecation warning: The backend.auth.keys config has been replaced by backend.auth.externalAccess Due to changes to the backend service-to-service authentication, you will see a deprecation warning if you have set up your deployment to use the backend.auth.keys field configured in upstream.backstage.appConfig This warning is harmless for now and no action is needed. IP addresses may appear in application logs If you deploy Developer Hub without a proxy, there is the potential for IP addresses to appear in the audit logs. If your organization's security policies restrict you from retaining IP addresses, you can take one or both of the following actions: Delete the IP addresses after they are collected. Prevent collection of IP addresses by configuring a reverse proxy in front of Developer Hub. Missing items in catalog or software templates after upgrade to Developer Hub 1.2 After upgrading to Developer Hub 1.2, user policies are not automatically migrated or updated, resulting in items not appearing in the catalog or software templates. To resolve this issue, after upgrading to version 1.2, users need to add the necessary policies in the Developer Hub RBAC system page. Rollbacks are not supported If you deploy Developer Hub using either Helm or the Operator, rollbacks to earlier versions are not supported. Performing regular backups of your Developer Hub PostgreSQL database helps you to restore the application to a recent state in case of issues. In future versions of Developer Hub, we plan to provide guidance on how to perform rollbacks from existing backups.

Commands:
Chapter 7. Troubleshooting After the RHEL 6 to RHEL 7 and RHEL 7 to RHEL 8 in-place upgrade, you might encounter package-related issues. You can troubleshoot and resolve many of these issues using the steps below. 7.1. Ensuring that installed packages match the current major RHEL version Ensure that only packages are installed that have been built for the currently installed major RHEL version: To display installed packages for a different major RHEL version: On RHEL 7, enter: On RHEL 8, enter: Remove or replace the packages reported in the step, because they are not supported. For details see the Can I install packages from different versions of RHEL? document. If the command in the step did not display any output, all installed packages were built for the installed major RHEL version and no further actions are required. After performing the in-place upgrade to RHEL 8, remove the kernel-workaround package: 7.2. Fixing dependency errors After an in-place upgrade, it is possible that packages are installed while some of their dependencies have been removed by the upgrade tool. To solve this problem: Identify dependencies errors: If the command displays no output, no further actions are required. To fix dependency errors, reinstall the affected packages. During this operation, the yum utility automatically installs missing dependencies. If the required dependencies are not available in the repositories, install these packages manually. 7.3. Installing missing packages after upgrading to RHEL 7 If you miss certain packages after the upgrade from RHEL 6 to RHEL 7, you probably did not provide a repository to the Red Hat Upgrade Tool that contained these packages. To install these packages after the upgrade, you can use, for example, the following commands: Note that different issues can prevent installing the RPMs. In this case, resolve the problems. For further details about other files with lists of packages you should install on the upgraded system, see the /root/preupgrade/kickstart/README file and the pre-upgrade report. 7.4. Known issues For known issues when upgrading: From RHEL 6 to RHEL 7, see the Known issues section in the Upgrading from RHEL 6 to RHEL 7 documentation From RHEL 7 to RHEL 8, see the known issues section in the Upgrading from RHEL 7 to RHEL 8 documentation 7.5. Additional resources Supported in-place upgrade paths for Red Hat Enterprise Linux Red Hat Enterprise Linux Life Cycle

Commands:
rpm -qa | grep -e '\.el6' | grep -vE '^(gpg-pubkey|katello-ca-consumer)' | sort
rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
yum -y remove kernel-workaround
yum check dependencies
cd /root/preupgrade bash noauto_postupgrade.d/install_rpmlist.sh kickstart/RHRHEL7rpmlist_kept
Chapter 5. Configuring the web console in OpenShift Container Platform You can modify the OpenShift Container Platform web console to set a logout redirect URL or disable the console. 5.1. Prerequisites Deploy an OpenShift Container Platform cluster. 5.2. Configuring the web console You can configure the web console settings by editing the console.config.openshift.io resource. Edit the console.config.openshift.io resource: USD oc edit console.config.openshift.io cluster The following example displays the sample resource definition for the console: apiVersion: config.openshift.io/v1 kind: Console metadata: name: cluster spec: authentication: logoutRedirect: "" 1 status: consoleURL: "" 2 1 Specify the URL of the page to load when a user logs out of the web console. If you do not specify a value, the user returns to the login page for the web console. Specifying a logoutRedirect URL allows your users to perform single logout (SLO) through the identity provider to destroy their single sign-on session. 2 The web console URL. To update this to a custom value, see Customizing the web console URL .

Commands:
oc edit console.config.openshift.io cluster
apiVersion: config.openshift.io/v1 kind: Console metadata: name: cluster spec: authentication: logoutRedirect: "" 1 status: consoleURL: "" 2
Chapter 3. Install and Use the Maven Repositories 3.1. About Maven Apache Maven is a distributed build automation tool used in Java application development to create, manage, and build software projects. Maven uses standard configuration files called Project Object Model (POM) files to define projects and manage the build process. POM files describe the module and component dependencies, build order, and targets for the resulting project packaging and output using an XML file. This ensures that the project is built correctly and in a uniform manner. Important Red Hat JBoss Data Grid requires Maven 3 (or better) for all quickstarts and general use. Visit the Maven Download page ( http://maven.apache.org/download.html ) for instructions to download and install Maven. Report a bug

Commands:
3.15. Port Mirroring Port mirroring copies layer 3 network traffic on a given logical network and host to a virtual interface on a virtual machine. This virtual machine can be used for network debugging and tuning, intrusion detection, and monitoring the behavior of other virtual machines on the same host and logical network. The only traffic copied is internal to one logical network on one host. There is no increase on traffic on the network external to the host; however a virtual machine with port mirroring enabled uses more host CPU and RAM than other virtual machines. Port mirroring is enabled or disabled in the vNIC profiles of logical networks, and has the following limitations: Hot plugging vNICs with a profile that has port mirroring enabled is not supported. Port mirroring cannot be altered when the vNIC profile is attached to a virtual machine. Given the above limitations, it is recommended that you enable port mirroring on an additional, dedicated vNIC profile. Important Enabling port mirroring reduces the privacy of other network users.

Commands:
2.7.7. Road Warrior Access VPN Using Libreswan Road warriors are traveling users with mobile clients with a dynamically assigned IP address, such as laptops. These are authenticated using certificates. On the server: Where: left= 1.2.3.4 The 1.2.3.4 value specifies the actual IP address or host name of your server. leftcert=vpn-server.example.com This option specifies a certificate referring to its friendly name or nickname that has been used to import the certificate. Usually, the name is generated as a part of a PKCS #12 certificate bundle in the form of a .p12 file. See the pkcs12(1) and pk12util(1) man pages for more information. On the mobile client, the road warrior's device, use a slight variation of the above configuration: Where: auto=start This option enables the user to connect to the VPN whenever the ipsec system service is started. Replace it with the auto=add if you want to establish the connection later.

Commands:
conn roadwarriors left=1.2.3.4 # if access to the LAN is given, enable this #leftsubnet=10.10.0.0/16 leftcert=vpn-server.example.com leftid=%fromcert right=%any # trust our own Certificate Agency rightca=%same # allow clients to be behind a NAT router rightsubnet=vhost:%priv,%no authby=rsasig # load connection, don't initiate auto=add # kill vanished roadwarriors dpddelay=30 dpdtimeout=120 dpdaction=%clear
conn roadwarriors # pick up our dynamic IP left=%defaultroute leftcert=myname.example.com leftid=%fromcert # right can also be a DNS hostname right=1.2.3.4 # if access to the remote LAN is required, enable this #rightsubnet=10.10.0.0/16 # trust our own Certificate Agency rightca=%same authby=rsasig # Initiate connection auto=start
18.3. Network Address Translation Mode By default, virtual network switches operate in NAT mode. They use IP masquerading rather than SNAT (Source-NAT) or DNAT (Destination-NAT). IP masquerading enables connected guests to use the host physical machine IP address for communication to any external network. By default, computers that are placed externally to the host physical machine cannot communicate to the guests inside when the virtual network switch is operating in NAT mode, as shown in the following diagram: Figure 18.3. Virtual network switch using NAT with two guests Warning Virtual network switches use NAT configured by iptables rules. Editing these rules while the switch is running is not recommended, as incorrect rules may result in the switch being unable to communicate. If the switch is not running, you can set th public IP range for forward mode NAT in order to create a port masquerading range by running: 18.3.1. DNS and DHCP IP information can be assigned to guests via DHCP. A pool of addresses can be assigned to a virtual network switch for this purpose. Libvirt uses the dnsmasq program for this. An instance of dnsmasq is automatically configured and started by libvirt for each virtual network switch that needs it. Figure 18.4. Virtual network switch running dnsmasq

Commands:
iptables -j SNAT --to-source [start]-[end]
Chapter 7. Set Up Distribution Mode 7.1. About Distribution Mode When enabled, Red Hat JBoss Data Grid's distribution mode stores each entry on a subset of the nodes in the grid instead of replicating each entry on every node. Typically, each entry is stored on more than one node for redundancy and fault tolerance. As a result of storing entries on selected nodes across the cluster, distribution mode provides improved scalability compared to other clustered modes. A cache using distribution mode can transparently locate keys across a cluster using the consistent hash algorithm. Report a bug

Commands:
Chapter 6. Enable cluster to auto-start after reboot The cluster is not yet enabled to auto-start after reboot. System admin needs to manually start the cluster after the node is fenced and rebooted. After testing the section, when everything works fine, enable the cluster to auto-start after reboot: [root@s4node1]# pcs cluster enable --all Note : In some situations it can be beneficial not to have the cluster auto-start after a node has been rebooted. For example, if there is an issue with a filesystem that is required by a cluster resource, and the filesystem needs to be repaired first before it can be used again, having the cluster auto-start can be a failure because the filesystem doesn't work. This can cause even more trouble. Now please rerun the tests in the section to make sure that the cluster still works fine. Please note that in section 5.3, there is no need to run command pcs cluster start after a node is rebooted. Cluster should automatically start after reboot. By this point you have successfully configured a two-node cluster for ENSA2. You can either continue with intensive testing to get ready for production or optionally add more nodes to the cluster.

Commands:
pcs cluster enable --all
2.3. Load Balancing Post connection load balancing can be utilized in one of two ways. If you are using the TeiidDataSource class and the PooledConnection returned by getPooledConnection is terminated using the close() method, then a new server instance will be selected automatically. (When using driver based connections or when using the TeiidDataSource class in a connection pool, the automatic load balancing will not happen.) Alternatively, you can explicitly trigger load balancing through the use of the set statement: SET NEWINSTANCE TRUE . Typically you will not issue this statement manually, but you can use it as the connection test query on your data source configuration: Important Session level temporary tables, currently running transactions, session level cache entries, and PreparedPlans for a given session will not be available on other cluster members. Therefore, it is recommended that post connection time load balancing is only used when the logical connection could have been closed, but the actual connection is reused. This is the typical connection pool pattern.

Commands:
<datasources> <datasource jndi-name="java:/teiidDS" pool-name="teiidDS"> <connection-url>jdbc:teiid:{vdb}@mm://{host}:31000</connection-url> <driver>teiid</driver> <pool> <prefill>false</prefill> <use-strict-min>false</use-strict-min> <flush-strategy>FailingConnectionOnly</flush-strategy> <check-valid-connection-sql>SET NEWINSTANCE TRUE</check-valid-connection-sql> </pool> <security> <user-name>{user}</user-name> <password>{password}</password> </security> </datasource> <drivers> <driver name="teiid" module="org.jboss.teiid.client"> <driver-class>org.teiid.jdbc.TeiidDriver</driver-class> <xa-datasource-class>org.teiid.jdbc.TeiidDataSource</xa-datasource-class> </driver> </drivers> </datasources>