mtpti5iD/redhat-docs_dataset huggingface dataset:
2.4. Configuring Fencing You must configure a fencing device for each node in the cluster. When configuring a fencing device, you should ensure that your fencing device does not share power with the node that it controls. For information on fence device configuration, see Section 4.6, "Configuring Fence Devices" . For information on configuring fencing for cluster nodes, see Section 4.7, "Configuring Fencing for Cluster Members" . After configuring a fence device for a node, it is important to test the fence device, to ensure that the cluster will cut off access to a resource when the cluster loses communication with that node. How you break communication with the node will depend on your system setup and the type of fencing you have configured. You may need to physically disconnect network cables, or force a kernel panic on the node. You can then check whether the node has been fenced as expected. When creating a two-node cluster, you may need to configure a tie-breaking mechanism for the cluster to avoid split brains and fence races for the cluster, which can occur when the cluster interconnect experiences issues that prevent the nodes from communicating. For information on avoiding fence races, see the Red Hat Knowledgebase solution "What are my options for avoiding fence races in RHEL 5, 6, and 7 High Availability clusters with an even number of nodes?" on Red Hat Customer Portal at https://access.redhat.com/solutions/91653 . For information on avoiding fencing loops, see the Red Hat Knowledgebase solution "How can I avoid fencing loops with 2 node clusters and Red Hat High Availability clusters?" on Red Hat Customer Portal at https://access.redhat.com/solutions/272913 .

Commands:
24.4.5. Using the du Command The du command allows you to displays the amount of space that is being used by files in a directory. To display the disk usage for each of the subdirectories in the current working directory, run the command with no additional command-line options: du For example: By default, the du command displays the disk usage in kilobytes. To view the information in megabytes and gigabytes, supply the -h command-line option, which causes the utility to display the values in a human-readable format: du -h For instance: At the end of the list, the du command always shows the grand total for the current directory. To display only this information, supply the -s command-line option: du -sh For example: For a complete list of available command-line options, see the du (1) manual page.

Commands:
~]USD du 14972 ./Downloads 4 ./.gnome2 4 ./.mozilla/extensions 4 ./.mozilla/plugins 12 ./.mozilla 15004 .
~]USD du -h 15M ./Downloads 4.0K ./.gnome2 4.0K ./.mozilla/extensions 4.0K ./.mozilla/plugins 12K ./.mozilla 15M .
~]USD du -sh 15M .
8.209. samba4 8.209.1. RHBA-2014:1605 - samba4 bug fix update Updated samba4 packages that fix one bug are now available for Red Hat Enterprise Linux 6. Samba is an open-source implementation of the Server Message Block (SMB) or Common Internet File System (CIFS) protocol, which allows PC-compatible machines to share files, printers, and other information. Users of samba4 are advised to upgrade to these updated packages, which fix this bug. After installing this update, the smb service will be restarted automatically.

Commands:
1.7. Global Network Block Device Global Network Block Device (GNBD) provides block-device access to Red Hat GFS over TCP/IP. GNBD is similar in concept to NBD; however, GNBD is GFS-specific and tuned solely for use with GFS. GNBD is useful when the need for more robust technologies - Fibre Channel or single-initiator SCSI - are not necessary or are cost-prohibitive. GNBD consists of two major components: a GNBD client and a GNBD server. A GNBD client runs in a node with GFS and imports a block device exported by a GNBD server. A GNBD server runs in another node and exports block-level storage from its local storage (either directly attached storage or SAN storage). Refer to Figure 1.19, "GNBD Overview" . Multiple GNBD clients can access a device exported by a GNBD server, thus making a GNBD suitable for use by a group of nodes running GFS. Figure 1.19. GNBD Overview

Commands:
Chapter 1. Overview Red Hat OpenShift Data Foundation is software-defined storage that is optimized for container environments. It runs as an operator on OpenShift Container Platform to provide highly integrated and simplified persistent storage management for containers. Red Hat OpenShift Data Foundation is integrated into the latest Red Hat OpenShift Container Platform to address platform services, application portability, and persistence challenges. It provides a highly scalable backend for the generation of cloud-native applications, built on a technology stack that includes Red Hat Ceph Storage, the Rook.io Operator, and NooBaa's Multicloud Object Gateway technology. Red Hat OpenShift Data Foundation is designed for FIPS. When running on RHEL or RHEL CoreOS booted in FIPS mode, OpenShift Container Platform core components use the RHEL cryptographic libraries submitted to NIST for FIPS Validation on only the x86_64, ppc64le, and s390X architectures. For more information about the NIST validation program, see Cryptographic Module Validation Program . For the latest NIST status for the individual versions of the RHEL cryptographic libraries submitted for validation, see Compliance Activities and Government Standards . Red Hat OpenShift Data Foundation provides a trusted, enterprise-grade application development environment that simplifies and enhances the user experience across the application lifecycle in a number of ways: Provides block storage for databases. Shared file storage for continuous integration, messaging, and data aggregation. Object storage for cloud-first development, archival, backup, and media storage. Scale applications and data exponentially. Attach and detach persistent data volumes at an accelerated rate. Stretch clusters across multiple data-centers or availability zones. Establish a comprehensive application container registry. Support the generation of OpenShift workloads such as Data Analytics, Artificial Intelligence, Machine Learning, Deep Learning, and Internet of Things (IoT). Dynamically provision not only application containers, but data service volumes and containers, as well as additional OpenShift Container Platform nodes, Elastic Block Store (EBS) volumes and other infrastructure services. 1.1. About this release Red Hat OpenShift Data Foundation 4.17 ( RHSA-2024:8676 ) is now available. New enhancements, features, and known issues that pertain to OpenShift Data Foundation 4.17 are included in this topic. Red Hat OpenShift Data Foundation 4.17 is supported on the Red Hat OpenShift Container Platform version 4.17. For more information, see Red Hat OpenShift Data Foundation Supportability and Interoperability Checker . For Red Hat OpenShift Data Foundation life cycle information, refer to the layered and dependent products life cycle section in Red Hat OpenShift Container Platform Life Cycle Policy .

Commands:
8.225. vhostmd 8.225.1. RHBA-2013:1579 - vhostmd bug fix update Updated vhostmd packages that fix one bug are now available for Red Hat Enterprise Linux 6 for SAP. The Virtual Host Metrics Daemon (vhostmd) provides virtual machines with information on the resource utilization of the Red Hat Enterprise Linux host on which they are being run. Bug Fix BZ# 820500 Due to bugs in the libmetrics code, user's programs could terminate with a segmentation fault when attempting to obtain guest metrics from vhostmd. The libmetrics code has been fixed to perform XPath queries and propagate errors to the user correctly so that the user's programs can now obtain guest metrics as expected. All users of vhostmd are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Appendix A. Revision History Revision History Revision 1.0-23 Mon March 10 2017 Jiri Herrmann Updates for the 6.9 GA release Revision 1.0-19 Mon May 02 2016 Jiri Herrmann Updates for the 6.8 GA release Revision 1.0-18 Tue Mar 01 2016 Jiri Herrmann Multiple updates for the 6.8 beta publication Revision 1.0-17 Thu Oct 08 2015 Jiri Herrmann Cleaned up the Revision History Revision 1.0-16 Wed July 15 2015 Dayle Parker Version for 6.7 GA release.

Commands:
Chapter 10. Backing up storage data from Google Persistent Disk Red Hat recommends that you back up the data on your persistent volume claims (PVCs) regularly. Backing up your data is particularly important before deleting a user and before uninstalling OpenShift AI, as all PVCs are deleted when OpenShift AI is uninstalled. Prerequisites You have credentials for Red Hat OpenShift Cluster Manager ( https://console.redhat.com/openshift/ ). You have administrator access to the OpenShift Dedicated cluster. You have credentials for the Google Cloud Platform (GCP) account that the OpenShift Dedicated cluster is deployed under. Procedure Determine the IDs of the persistent volumes (PVs) that you want to back up. In the OpenShift Dedicated web console, change into the Administrator perspective. Click Home Projects . Click the rhods-notebooks project. The Details page for the project opens. Click the PersistentVolumeClaims in the Inventory section. The PersistentVolumeClaims page opens. Note the ID of the persistent volume (PV) that you want to back up. The persistent volume (PV) IDs are required to identify the correct persistent disk to back up in your GCP instance. Locate the persistent disk containing the PVs that you want to back up. Log in to the Google Cloud console ( https://console.cloud.google.com ) and ensure that you are viewing the region that your OpenShift Dedicated cluster is deployed in. Click the navigation menu (≡) and then click Compute Engine . From the side navigation, under Storage , click Disks . The Disks page opens. In the Filter query box, enter the ID of the persistent volume (PV) that you made a note of earlier. The Disks page reloads to display the search results. Click on the disk shown and verify that any kubernetes.io/created-for/pvc/namespace tags contain the value rhods-notebooks , and any kubernetes.io/created-for/pvc/name tags match the name of the persistent volume that the persistent disk is being used for, for example, jupyterhub-nb-user1-pvc . Back up the persistent disk that contains your persistent volume (PV). Select CREATE SNAPSHOT from the top navigation. The Create a snapshot page opens. Enter a unique Name for the snapshot. Under Source disk , verify the persistent disk you want to back up is displayed. Change any optional settings as needed. Click CREATE . The snapshot of the persistent disk is created. Verification The snapshot that you created is visible on the Snapshots page in GCP. Additional resources Google Cloud documentation: Create and manage disk snapshots

Commands:
8.49. edac-utils 8.49.1. RHBA-2014:0768 - edac-utils bug fix update An updated edac-utils package that fixes one bug is now available for Red Hat Enterprise Linux 6. Error Detection And Correction (EDAC) is the current set of drivers in the Linux kernel that handles detection of ECC errors from memory controllers for most chipsets on the 32-bit x86, AMD64, and Intel 64 architectures. The user-space component consists of an init script which ensures that EDAC drivers and DIMM labels are loaded at system startup, as well as a library and utility for reporting current error counts from the EDAC sysfs files. Bug Fix BZ# 679812 Previously, the exit status of the edac-utils package init script was not set correctly. As a consequence, running the 'service edac status' command returned exit status 0, which was not expected behavior because no programs were running after executing the 'service edac start' command. With this update, the returned exit status has been changed to 3 in the described situation. Users of edac-utils are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 6. Creating a kernel-based virtual machine and booting the installation ISO in the VM You can create a kernel-based virtual machine (KVM) and start the Red Hat Enterprise Linux installation. The following instructions are specific for installation on a VM. If you are installing RHEL on a physical system, you can skip this section. Procedure Create a virtual machine with the instance of Red Hat Enterprise Linux as a KVM guest operating system, by using the following virt-install command on the KVM host: Additional resources virt-install man page on your system Creating virtual machines by using the command line

Commands:
virt-install --name=<guest_name> --disk size=<disksize_in_GB> --memory=<memory_size_in_MB> --cdrom <filepath_to_iso> --graphics vnc
Preface You can use a host with a compatible graphics processing unit (GPU) to run virtual machines in Red Hat Virtualization that are suited for graphics-intensive tasks and for running software that cannot run without a GPU, such as CAD. You can assign a GPU to a virtual machine in one of the following ways: GPU passthrough : You can assign a host GPU to a single virtual machine, so the virtual machine, instead of the host, uses the GPU. Virtual GPU (vGPU) : You can divide a physical GPU device into one or more virtual devices, referred to as mediated devices . You can then assign these mediated devices to one or more virtual machines as virtual GPUs. These virtual machines share the performance of a single physical GPU. For some GPUs, only one mediated device can be assigned to a single guest. vGPU support is only available on selected NVIDIA GPUs. Example: A host has four GPUs. Each GPU can support up to 16 vGPUs, for a total of 64 vGPUs. Some possible vGPU assignments are: one virtual machine with 64 vGPUs 64 virtual machines, each with one vGPU 32 virtual machines, each with one vGPU; eight virtual machines, each with two vGPUs; 4 virtual machines, each with four vGPUs

Commands:
Chapter 1. Red Hat build of OpenJDK 11 - Extended Lifecycle Support Phase 1 Important The 11.0.25 release in October 2024 was the last release of Red Hat build of OpenJDK 11 from Red Hat in the full support phase of the lifecycle. The full support phase for Red Hat build of OpenJDK 11 ended on 31 October 2024. See the Product Life Cycles page for details. From November 2024 onward, Red Hat will provide extended lifecycle support phase 1 (ELS‐1) support for new releases of Red Hat build of OpenJDK 11 until 31 October 2027. Access to ELS requires an OpenJDK ELS subscription. OpenJDK ELS is not included in any other ELS subscription. For more information about product lifecycle phases and available support levels, see Life Cycle Phases . For information about migrating to Red Hat build of OpenJDK version 17 or 21, see Migrating to Red Hat build of OpenJDK 17 from earlier versions or Migrating to Red Hat build of OpenJDK 21 from earlier versions .

Commands:
Chapter 4. Upgrading Red Hat JBoss Web Server using this Service Pack To install this service pack: Go to the Software Downloads page for Red Hat JBoss Web Server 6.0 . Note You require a Red Hat subscription to access the Software Downloads page. Download the Red Hat JBoss Web Server 6.0 Service Pack 1 archive file that is appropriate to your platform. Extract the archive file to the Red Hat JBoss Web Server installation directory. If you have installed Red Hat JBoss Web Server from RPM packages on Red Hat Enterprise Linux, you can use the following yum command to upgrade to the latest service pack:

Commands:
yum upgrade
3.2. GNOME and KDE System Monitors The GNOME and KDE desktop environments both have graphical tools to assist you in monitoring and modifying the behavior of your system. GNOME System Monitor The GNOME System Monitor displays basic system information and allows you to monitor system processes, and resource or file system usage. Open it with the gnome-system-monitor command in the Terminal , or click on the Applications menu, and select System Tools > System Monitor . GNOME System Monitor has four tabs: System Displays basic information about the computer's hardware and software. Processes Shows active processes, and the relationships between those processes, as well as detailed information about each process. It also lets you filter the processes displayed, and perform certain actions on those processes (start, stop, kill, change priority, etc.). Resources Displays the current CPU time usage, memory and swap space usage, and network usage. File Systems Lists all mounted file systems alongside some basic information about each, such as the file system type, mount point, and memory usage. For further information about the GNOME System Monitor , refer to the Help menu in the application, or to the Deployment Guide , available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ . KDE System Guard The KDE System Guard allows you to monitor current system load and processes that are running. It also lets you perform actions on processes. Open it with the ksysguard command in the Terminal , or click on the Kickoff Application Launcher and select Applications > System > System Monitor . There are two tabs to KDE System Guard : Process Table Displays a list of all running processes, alphabetically by default. You can also sort processes by a number of other properties, including total CPU usage, physical or shared memory usage, owner, and priority. You can also filter the visible results, search for specific processes, or perform certain actions on a process. System Load Displays historical graphs of CPU usage, memory and swap space usage, and network usage. Hover over the graphs for detailed analysis and graph keys. For further information about the KDE System Guard , refer to the Help menu in the application.

Commands:
Chapter 1. Updating a model Red Hat Enterprise Linux AI allows you to upgrade LLMs that you locally downloaded to the latest version of the model. 1.1. Updating the models You can upgrade your local models to the latest version of the model using the RHEL AI tool set. Prerequisites You installed the InstructLab tools with the bootable container image. You initialized InstructLab and can use the ilab CLI. You downloaded LLMs on Red Hat Enterprise Linux AI. You created a Red Hat registry account and logged in on your machine. Procedure You can upgrade any model by running the following command. USD ilab model download --repository <repository_and_model> --release latest where: <repository_and_model> Specifies the repository location of the model as well as the model. You can access the models from the registry.redhat.io/rhelai1/ repository. <release> Specifies the version of the model. Set to latest , or a specific version of the model, for the most up to date version of the model. Verification You can view all the downloaded models on your system with the following command: USD ilab model list

Commands:
ilab model download --repository <repository_and_model> --release latest
ilab model list
5.4.3.2. Splitting Off a Redundant Image of a Mirrored Logical Volume You can split off a redundant image of a mirrored logical volume to form a new logical volume. To split off an image, you use the --splitmirrors argument of the lvconvert command, specifying the number of redundant images to split off. You must use the --name argument of the command to specify a name for the newly-split-off logical volume. The following command splits off a new logical volume named copy from the mirrored logical volume vg/lv . The new logical volume contains two mirror legs. In this example, LVM selects which devices to split off. You can specify which devices to split off. The following command splits off a new logical volume named copy from the mirrored logical volume vg/lv . The new logical volume contains two mirror legs consisting of devices /dev/sdc1 and /dev/sde1 .

Commands:
lvconvert --splitmirrors 2 --name copy vg/lv
lvconvert --splitmirrors 2 --name copy vg/lv /dev/sd[ce]1
Chapter 1. Updating Satellite to the patch version You can update your Satellite Server and Capsule Server to a new patch release version, such as from 6.16.0 to 6.16.1, by using the Satellite maintain tool. The patch releases are non-disruptive to your operating environment and often fast. You can update the underlying operating system. If there are pending Satellite Server updates, updating the operating system will update both. Important Perform updates regularly to resolve security vulnerabilities and other issues.

Commands:
Chapter 1. Upgrade overview The upgrade procedure for Red Hat Quay depends on the type of installation you are using. The Red Hat Quay Operator provides a simple method to deploy and manage a Red Hat Quay cluster. This is the preferred procedure for deploying Red Hat Quay on OpenShift. The Red Hat Quay Operator should be upgraded using the Operator Lifecycle Manager (OLM) as described in the section "Upgrading Quay using the Quay Operator". The procedure for upgrading a proof-of-concept or highly available installation of Red Hat Quay and Clair is documented in the section "Standalone upgrade".

Commands:
Chapter 1. Post-installation configuration overview After installing OpenShift Container Platform, a cluster administrator can configure and customize the following components: Machine Cluster Node Network Storage Users Alerts and notifications 1.1. Configuration tasks to perform after installation Cluster administrators can perform the following post-installation configuration tasks: Configure operating system features : Machine Config Operator (MCO) manages MachineConfig objects. By using MCO, you can perform the following tasks on an OpenShift Container Platform cluster: Configure nodes by using MachineConfig objects Configure MCO-related custom resources Configure cluster features : As a cluster administrator, you can modify the configuration resources of the major features of an OpenShift Container Platform cluster. These features include: Image registry Networking configuration Image build behavior Identity provider The etcd configuration Machine set creation to handle the workloads Cloud provider credential management Configure cluster components to be private : By default, the installation program provisions OpenShift Container Platform by using a publicly accessible DNS and endpoints. If you want your cluster to be accessible only from within an internal network, configure the following components to be private: DNS Ingress Controller API server Perform node operations : By default, OpenShift Container Platform uses Red Hat Enterprise Linux CoreOS (RHCOS) compute machines. As a cluster administrator, you can perform the following operations with the machines in your OpenShift Container Platform cluster: Add and remove compute machines Add and remove taints and tolerations to the nodes Configure the maximum number of pods per node Enable Device Manager Configure network : After installing OpenShift Container Platform, you can configure the following: Ingress cluster traffic Node port service range Network policy Enabling the cluster-wide proxy Configure storage : By default, containers operate using ephemeral storage or transient local storage. The ephemeral storage has a lifetime limitation. TO store the data for a long time, you must configure persistent storage. You can configure storage by using one of the following methods: Dynamic provisioning : You can dynamically provision storage on demand by defining and creating storage classes that control different levels of storage, including storage access. Static provisioning : You can use Kubernetes persistent volumes to make existing storage available to a cluster. Static provisioning can support various device configurations and mount options. Configure users : OAuth access tokens allow users to authenticate themselves to the API. As a cluster administrator, you can configure OAuth to perform the following tasks: Specify an identity provider Use role-based access control to define and supply permissions to users Install an Operator from OperatorHub Manage alerts and notifications : By default, firing alerts are displayed on the Alerting UI of the web console. You can also configure OpenShift Container Platform to send alert notifications to external systems.

Commands: