mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. The Red Hat bare metal hardware certification program overview Red Hat OpenStack Platform and Red Hat OpenShift Container Platform bare metal hardware certification creates value for customers as the server can be managed and automatically deployed and redeployed with Red Hat OpenStack Platform and Red Hat OpenShift Container Platform, without manual intervention. The certification process, through a series of tests, validates that a certified solution meets the requirements of an enterprise cloud and is jointly supported by Red Hat and your organization. The following diagrams illustrate the bare-metal certification workflow for OpenShift and OpenStack: Figure 3.1. Red Hat OpenStack Platform Bare Metal Hardware certification process Figure 3.2. Red Hat OpenShift Container Platform Bare Metal Hardware certification process Most of the certification subtests provide an immediate return status (Pass/Fail); Some subtests may require detailed review by Red Hat to confirm success or failure. Such tests are marked with REVIEW status in Red Hat Certification application. Some tests may also identify a potential issue and return a WARN status. This status indicates that best practices may not have been followed. Tests marked with the WARN status warrant attention or actions but do not prevent a certification from publishing. You should review the output of such tests and perform appropriate actions based on the information contained within the warnings. For information about the certification prerequisites, see the policy guide .

Commands:
7.288. xorg-x11 7.288.1. RHEA-2013:0301 - xorg-x11 drivers enhancement update Updated xorg-x11 drivers packages that add numerous enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11 drivers packages allow the OS installation software to install all drivers all at once, without having to track which individual drivers are present on each architecture. By installing these packages, it forces all of the individual driver packages to be installed. The following xorg-x11 drivers packages have been upgraded to their upstream versions to update several legacy GPU drivers: Table 7.4. Upgraded packages Package name Upstream version BZ number xorg-x11-drv-apm 1.2.5 835216 xorg-x11-drv-ast 0.97.0 835217 xorg-x11-drv-cirrus 1.5.1 835219 xorg-x11-drv-dummy 0.3.6 835220 xorg-x11-drv-fbdev 0.4.3 835228 xorg-x11-drv-geode 2.11.13 835230 xorg-x11-drv-glint 1.2.8 835231 xorg-x11-drv-i128 1.3.6 835234 xorg-x11-drv-i740 1.3.4 835235 xorg-x11-drv-mach64 6.9.3 835239 xorg-x11-drv-mga 1.6.1 835240 xorg-x11-drv-neomagic 1.2.7 835244 xorg-x11-drv-nv 2.1.20 835246 xorg-x11-drv-openchrome 0.3.0 835247 xorg-x11-drv-r128 6.9.1 835250 xorg-x11-drv-rendition 4.2.5 835251 xorg-x11-drv-s3virge 1.10.6 835252 xorg-x11-drv-savage 2.3.6 835253 xorg-x11-drv-siliconmotion 1.7.7 835254 xorg-x11-drv-sis 0.10.7 835255 xorg-x11-drv-sisusb 0.9.6 835256 xorg-x11-drv-tdfx 1.4.5 835258 xorg-x11-drv-v4l 0.2.0 835260 xorg-x11-drv-trident 1.3.6 835259 xorg-x11-drv-vesa 2.3.2 835261 xorg-x11-drv-vmware 12.0.2 835263 xorg-x11-drv-voodoo 1.2.5 835265 xorg-x11-drv-xgi 1.6.0 835267 xorg-x11-drivers 7.3 835285 Users of xorg-x11-drv are advised to upgrade to these updated packages, which add various enhancements.

Commands:
E.3.2. /proc/bus/ This directory contains information specific to the various buses available on the system. For example, on a standard system containing PCI and USB buses, current data on each of these buses is available within a subdirectory within /proc/bus/ by the same name, such as /proc/bus/pci/ . The subdirectories and files available within /proc/bus/ vary depending on the devices connected to the system. However, each bus type has at least one directory. Within these bus directories are normally at least one subdirectory with a numerical name, such as 001 , which contain binary files. For example, the /proc/bus/usb/ subdirectory contains files that track the various devices on any USB buses, as well as the drivers required for them. The following is a sample listing of a /proc/bus/usb/ directory: The /proc/bus/usb/001/ directory contains all devices on the first USB bus and the devices file identifies the USB root hub on the motherboard. The following is a example of a /proc/bus/usb/devices file:

Commands:
total 0 dr-xr-xr-x 1 root root 0 May 3 16:25 001 -r--r--r-- 1 root root 0 May 3 16:25 devices -r--r--r-- 1 root root 0 May 3 16:25 drivers
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
2.2.5. GNOME Power Manager The backend program of the GNOME power management infrastructure is gnome-power-manager . It was introduced in Red Hat Enterprise Linux 5 and provides a complete and integrated solution to power management under the GNOME desktop environment. In Red Hat Enterprise Linux 6, the storage-handling parts of hal was replaced by udisks , and the libgnomeprint stack was replaced by print support in gtk2 . 2.2.5.1. GNOME Power Management Version Guide This section will detail what versions of gnome-power-management are shipped with the various Red Hat Enterprise Linux versions. In general, however, Red Hat Enterprise Linux 4 ships with GNOME 2.8, Red Hat Enterprise Linux 5 ships with GNOME 2.16, and Red Hat Enterprise Linux 6 ships with GNOME 2.28. Table 2.1. Desktop Components Comparison Red Hat Enterprise Linux Version GNOME Power Management Desktop Components 4 5 6 hal 0.4.2 0.5.8 0.5.14 udisks N/A N/A 1.0.1 glib2 2.4.7 2.12.3 2.22.5 gtk2 2.4.13 2.10.4 2.18.9 gnome-vfs2 2.8.2 2.16.2 2.24.2 libglade2 2.4.0 2.6.0 2.6.4 libgnomecanvas 2.8.0 2.14.0 2.26.0 gnome-desktop 2.8.0 2.16.0 2.28.2 gnome-media 2.8.0 2.16.1 2.29.91 gnome-python2 2.6.0 2.16.0 2.28.0 libgnome 2.8.0 2.16.0 2.28.0 libgnomeui 2.8.0 2.16.0 2.24.1 libgnomeprint22 2.8.0 2.12.1 N/A libgnomeprintui22 2.8.0 2.12.1 N/A gnome-session 2.8.0 2.16.0 2.28.0 gnome-power-manager N/A 2.16.0 2.28.3 gnome-applets 2.8.0 2.16.0 2.28.0 gnome-panel 2.8.1 2.16.1 2.30.2

Commands:
Appendix A. Revision History Revision History Revision 1.0-11.400 2013-10-31 Rudiger Landmann Rebuild with publican 4.0.0 Revision 1.0-11 2012-07-18 Anthony Towns Rebuild for Publican 3.0 Revision 4.9-1 Wed Feb 16 2011 Steven Levine Resolves: #633518 Fixes typo. Revision 1.0-0 Wed Apr 01 2009

Commands:
Chapter 12. Kafka Streams API overview The Kafka Streams API allows applications to receive data from one or more input streams, execute complex operations like mapping, filtering or joining, and write the results into one or more output streams. It is part of the kafka-streams JAR package that is available in the Red Hat Maven repository. 12.1. Adding the Kafka Streams API as a dependency to your Maven project This procedure shows you how to add the AMQ Streams Java clients as a dependency to your Maven project. Prerequisites A Maven project with an existing pom.xml . Procedure Add the Red Hat Maven repository to the <repositories> section of your pom.xml file. Add kafka-streams to the <dependencies> section of your pom.xml file. Build your Maven project.

Commands:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <repositories> <repository> <id>redhat-maven</id> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <!-- ... --> </project>
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <dependencies> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-streams</artifactId> <version>2.6.0.redhat-00004</version> </dependency> </dependencies> <!-- ... --> </project>
Chapter 11. Registering RHEL by using Subscription Manager Post-installation, you must register your system to get continuous updates. 11.1. Registering RHEL 9 using the installer GUI You can register a Red Hat Enterprise Linux 9 by using the RHEL installer GUI. Prerequisites You have a valid user account on the Red Hat Customer Portal. See the Create a Red Hat Login page . You have a valid Activation Key and Organization id. Procedure From the Installation Summary screen, under Software , click Connect to Red Hat . Authenticate your Red Hat account using the Account or Activation Key option. Optional: In the Set System Purpose field select the Role , SLA , and Usage attribute that you want to set from the drop-down menu. At this point, your Red Hat Enterprise Linux 9 system has been successfully registered. 11.2. Registration Assistant Registration Assistant is designed to help you choose the most suitable registration option for your Red Hat Enterprise Linux environment. Additional resources For assistance with using a username and password to register RHEL with the Subscription Manager client, see the RHEL registration assistant on the Customer Portal. For assistance with registering your RHEL system to Red Hat Insights, see the Insights registration assistant on the Hybrid Cloud Console. 11.3. Registering your system using the command line You can register your Red Hat Enterprise Linux 9 subscription by using the command line. For an improved and simplified experience registering your hosts to Red Hat, use remote host configuration (RHC). The RHC client registers your system to Red Hat making your system ready for Insights data collection and enabling direct issue remediation from Insights for Red Hat Enterprise Linux. For more information, see RHC registration . Prerequisites You have an active, non-evaluation Red Hat Enterprise Linux subscription. Your Red Hat subscription status is verified. You have not previously received a Red Hat Enterprise Linux 9 subscription. You have successfully installed Red Hat Enterprise Linux 9 and logged into the system as root. Procedure Open a terminal window as a root user. Register your Red Hat Enterprise Linux system by using the activation key: When the system is successfully registered, an output similar to the following is displayed: Additional resources Using an activation key to register a system with Red Hat Subscription Manager Getting Started with RHEL System Registration

Commands:
subscription-manager register --activationkey= <activation_key_name> --org= <organization_ID>
The system has been registered with id: 62edc0f8-855b-4184-b1b8-72a9dc793b96
7.170. PackageKit 7.170.1. RHBA-2013:0394 - PackageKit bug fix update Updated PackageKit packages that fix one bug are now available for Red Hat Enterprise Linux 6. The PackageKit packages provide a D-Bus abstraction layer that allows the session user to manage packages in a secure way using a cross-distribution, cross-architecture API. Bug Fix BZ#735597 Prior to this update, the PackageKit daemon could abort with a segmentation fault when the user tried to authenticate with PolicyKit if the "/usr/sbin/consolekit" process failed or was manually stopped. This update modifies the underlying code so that PackageKit no longer fails when unable to access ConsoleKit. Now, a console warning message is displayed for PackageKit instead. All users of PackageKit are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 1. About disconnected environments A disconnected environment is an environment that does not have full access to the internet. OpenShift Container Platform is designed to perform many automatic functions that depend on an internet connection, such as retrieving release images from a registry or retrieving update paths and recommendations for the cluster. Without a direct internet connection, you must perform additional setup and configuration for your cluster to maintain full functionality in the disconnected environment. 1.1. Glossary of disconnected environment terms Although it is used throughout the OpenShift Container Platform documentation, disconnected environment is a broad term that can refer to environments with various levels of internet connectivity. Other terms are sometimes used to refer to a specific level of internet connectivity, and these environments might require additional unique configurations. The following table describes the different terms used to refer to environments without a full internet connection: Table 1.1. Disconnected environment terms Term Description Air-gapped network An environment or network that is completely isolated from an external network. This isolation depends on a physical separation, or an "air gap", between machines on the internal network and any other part of an external network. Air-gapped environments are often used in industries with strict security or regulatory requirements. Disconnected environment An environment or network that has some level of isolation from an external network. This isolation could be enabled by physical or logical separation between machines on the internal network and an external network. Regardless of the level of isolation from the external network, a cluster in a disconnected environment does not have access to public services hosted by Red Hat and requires additional setup to maintain full cluster functionality. Restricted Network An environment or network with limited connection to an external network. A physical connection may exist between machines on the internal network and an external network, but network traffic is limited by additional configurations, such as with firewalls and proxies. 1.2. Preferred methods for working with disconnected environments You can choose between multiple options for most aspects of managing a cluster in a disconnected environment. For example, when mirroring images you can choose between using the oc-mirror OpenShift CLI ( oc ) plugin or using the oc adm command. However, some options provide a simpler and more convenient user experience for disconnected environments, and are the preferred method over their alternatives. Unless your organizational needs require you to choose another option, use the following methods for mirroring images, installing your cluster, and updating your cluster: Mirror your images using the oc-mirror plugin . Install your cluster using the Agent-based Installer . Update your cluster using a local OpenShift Update Service instance .

Commands:
Chapter 3. Recovery for HA applications with RWX storage Applications that are using topologyKey: kubernetes.io/hostname or no topology configuration, have no protection against all of the application replicas being in the same zone. Note This can happen even with podAntiAffinity and topologyKey: kubernetes.io/hostname in the Pod spec because this anti-affinity rule is host-based and not zone-based. If this happens and all replicas are located in the zone that fails, the application using ReadWriteMany (RWX) storage takes 6-8 minutes to recover on the active zone. This pause is for the OpenShift Container Platform nodes in the failed zone to become NotReady (60 seconds) and then for the default pod eviction timeout to expire (300 seconds).

Commands:
3.2.3.2. Increasing the Capacity Of course, if it is not possible to reduce the demand for processing power, you must find ways of increasing the processing power that is available. To do so costs money, but it can be done. 3.2.3.2.1. Upgrading the CPU The most straightforward approach is to determine if your system's CPU can be upgraded. The first step is to determine if the current CPU can be removed. Some systems (primarily laptops) have CPUs that are soldered in place, making an upgrade impossible. The rest, however, have socketed CPUs, making upgrades possible -- at least in theory. , you must do some research to determine if a faster CPU exists for your system configuration. For example, if you currently have a 1GHz CPU, and a 2GHz unit of the same type exists, an upgrade might be possible. Finally, you must determine the maximum clock speed supported by your system. To continue the example above, even if a 2GHz CPU of the proper type exists, a simple CPU swap is not an option if your system only supports processors running at 1GHz or below. Should you find that you cannot install a faster CPU in your system, your options may be limited to changing motherboards or even the more expensive forklift upgrade mentioned earlier. However, some system configurations make a slightly different approach possible. Instead of replacing the current CPU, why not just add another one?

Commands:
Chapter 10. Rebooting the environment A situation might occur where you need to reboot the environment. For example, when you might need to modify the physical servers, or you might need to recover from a power outage. In this situation, it is important to make sure your Ceph Storage nodes boot correctly. Make sure to boot the nodes in the following order: Boot all Ceph Monitor nodes first - This ensures the Ceph Monitor service is active in your high availability cluster. By default, the Ceph Monitor service is installed on the Controller node. If the Ceph Monitor is separate from the Controller in a custom role, make sure this custom Ceph Monitor role is active. Boot all Ceph Storage nodes - This ensures the Ceph OSD cluster can connect to the active Ceph Monitor cluster on the Controller nodes. 10.1. Rebooting a Ceph Storage (OSD) cluster Complete the following steps to reboot a cluster of Ceph Storage (OSD) nodes. Procedure Log in to a Ceph MON or Controller node and disable Ceph Storage cluster rebalancing temporarily: Select the first Ceph Storage node that you want to reboot and log in to the node. Reboot the node: Wait until the node boots. Log in to the node and check the cluster status: Check that the pgmap reports all pgs as normal ( active+clean ). Log out of the node, reboot the node, and check its status. Repeat this process until you have rebooted all Ceph storage nodes. When complete, log into a Ceph MON or Controller node and re-enable cluster rebalancing: Perform a final status check to verify that the cluster reports HEALTH_OK : If a situation occurs where all overcloud nodes boot at the same time, the Ceph OSD services might not start correctly on the Ceph Storage nodes. In this situation, reboot the Ceph Storage OSDs so they can connect to the Ceph Monitor service. Verify a HEALTH_OK status of the Ceph Storage node cluster with the following command:

Commands:
sudo podman exec -it ceph-mon-controller-0 ceph osd set noout sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance
sudo reboot
sudo podman exec -it ceph-mon-controller-0 ceph status
sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance
sudo podman exec -it ceph-mon-controller-0 ceph status
sudo ceph status
1.4. Storage Red Hat Virtualization uses a centralized storage system for virtual disks, templates, snapshots, and ISO files. Storage is logically grouped into storage pools, which are comprised of storage domains. A storage domain is a combination of storage capacity and metadata that describes the internal structure of the storage. There are three types of storage domain; data, export, and ISO. The data storage domain is the only one required by each data center. A data storage domain is exclusive to a single data center. Export and ISO domains are optional. Storage domains are shared resources, and must be accessible to all hosts in a data center. Storage networking can be implemented using Network File System (NFS), Internet Small Computer System Interface (iSCSI), GlusterFS, Fibre Channel Protocol (FCP), or any POSIX compliant networked filesystem. On NFS (and other POSIX-compliant filesystems) domains, all virtual disks, templates, and snapshots are simple files. On SAN (iSCSI/FCP) domains, block devices are aggregated by Logical Volume Manager (LVM)into a Volume Group (VG). Each virtual disk, template and snapshot is a Logical Volume (LV) on the VG. See the Red Hat Enterprise Linux Logical Volume Manager Administration Guide for more information on LVM. Data storage domain Data domains hold the virtual hard disk images of all the virtual machines running in the environment. Templates and snapshots of the virtual machines are also stored in the data domain. A data domain cannot be shared across data centers. Export storage domain An export domain is a temporary storage repository that is used to copy and move images between data centers and Red Hat Virtualization environments. The export domain can be used to back up virtual machines and templates. An export domain can be moved between data centers, but can only be active in one data center at a time. ISO storage domain ISO domains store ISO files, which are logical CD-ROMs used to install operating systems and applications for the virtual machines. As a logical entity that replaces a library of physical CD-ROMs or DVDs, an ISO domain removes the data center's need for physical media. An ISO domain can be shared across different data centers.

Commands:
2.4. Fibre Channel Storage Network Table 2.2, "Fibre Channel Network Requirements" shows requirements for GFS nodes that are to be connected to a Fibre Channel SAN. Table 2.2. Fibre Channel Network Requirements Requirement Description HBA (Host Bus Adapter) One HBA minimum per GFS node Connection method Fibre Channel switch Note: If an FC switch is used for fencing, you may want to consider using Brocade, McData, or Vixel FC switches, for which Red Hat Cluster Suite fencing agents exist. Refer to Configuring and Managing a Red Hat Cluster for more information about supported fencing agents. Note: When a small number of nodes is used, it may be possible to connect the nodes directly to ports on the storage device. Note: FC drivers may not work reliably with FC hubs.

Commands: