mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction to RHOSO certification program Certify your infrastructure and applications deployed on Red Hat OpenStack Services on OpenShift (RHOSO). 1.1. The Red Hat certification program overview The Red Hat certification program ensures the compatibility of your applications deployed on Red Hat OpenStack Services on OpenShift (RHOSO). The program has three main elements: Test suite - Contains tests for hardware or software applications undergoing certification. Red Hat Certification Ecosystem - Helps to explore and find certified products including hardware, software, cloud, and service providers. Support - Provides a joint support relationship between you and Red Hat. This table summarizes the basic differences between a product listing and components: Product listing Component (Project) Includes detailed information about your product. The individual containers, operators, helm charts, and infrastructure services that you test, certify, and then add to the product listing. Products are composed of one or more components. Components are added to a product listing. You add components to a product for proceeding with certification. A component can be used in multiple products by adding it to each product listing. A product can not be published without certified components. Certified components are published as part of a product listing. 1.2. The RHOSO certification workflow Note Red Hat recommends that you are a Red Hat Certified Engineer or hold equivalent experience before starting the certification process. The following diagram gives an overview of the certification process. Figure 1.1. The RHOSO certification workflow 1.3. Getting support and giving feedback For any questions related to the Red Hat certification toolset, certification process, or procedure described in this documentation, refer to the KB Articles , Red Hat Customer Portal , and Red Hat Partner Connect . You can also open a support case to get support or submit feedback. To open a support case see, How do I open and manage a support case on the Customer Portal? Questions during certification If you have any questions about a specific certification, record them in the Comments section of the Dialog Tab of the certification entry. Warning If you face any preliminary issues that stop you from proceeding with the product certification, contact your Engineering Partner Manager or other engineering engagements to resolve them.

Commands:
B.38.11. RHBA-2011:1412 - kernel bug fix update Updated kernel packages that fix one bug are now available for Red Hat Enterprise Linux 6 Extended Update Support. The kernel packages contain the Linux kernel, the core of any Linux operating system. Bug Fix BZ# 695256 While executing a multi-threaded process by multiple CPUs, page-directory-pointer-table entry (PDPTE) registers were not fully flushed from the CPU cache when a Page Global Directory (PGD) entry was changed in x86 Physical Address Extension (PAE) mode. As a consequence, the process failed to respond for a long time before it successfully finished. With this update, the kernel has been modified to flush the Translation Lookaside Buffer (TLB) for each CPU using a page table that has changed. Multi-threaded processes now finish without hanging. All users of kernel are advised to upgrade to these updated packages, which fix this bug. The system must be rebooted for this update to take effect.

Commands:
Chapter 7. Fixed issues ENTMQIC-2752 - Some details missing on dispositions forwarded by router on transacted sessions Previously, as messages moved from a client through a router to a broker in a transacted session, the disposition from the broker was not forwarded from the router back to the client. This issue has been resolved. ENTMQIC-2624 - Provide example yaml files for installation of operator and container image Previously, if you wanted to use the AMQ Interconnect Operator, you had to provision it using the OperatorHub. The release includes files and instructions to provision the operator from the command-line. ENTMQIC-2427 - In qpid-dispatch-console the addresses page is not showing the ingress and egress counts properly Previously, the AMQ Management Console might incorrectly display 0 for delivery attribute values associated with mobile addresses. This issue has been resolved.

Commands:
2.3.3. Inattentive Administration Administrators who fail to patch their systems are one of the greatest threats to server security. According to the System Administration Network and Security Institute ( SANS ), the primary cause of computer security vulnerability is to "assign untrained people to maintain security and provide neither the training nor the time to make it possible to do the job." [4] This applies as much to inexperienced administrators as it does to overconfident or amotivated administrators. Some administrators fail to patch their servers and workstations, while others fail to watch log messages from the system kernel or network traffic. Another common error is when default passwords or keys to services are left unchanged. For example, some databases have default administration passwords because the database developers assume that the system administrator changes these passwords immediately after installation. If a database administrator fails to change this password, even an inexperienced cracker can use a widely-known default password to gain administrative privileges to the database. These are only a few examples of how inattentive administration can lead to compromised servers. [4] Source: https://www.sans.org/reading_room/whitepapers/hsoffice/addressing_and_i mplementing_computer_security_for_a_small_branch_office_620

Commands:
4.6. Configuring the Default Gateway The default gateway is determined by the network scripts which parse the /etc/sysconfig/network file first and then the network interface ifcfg files for interfaces that are " up " . The ifcfg files are parsed in numerically ascending order, and the last GATEWAY directive to be read is used to compose a default route in the routing table. You can specify the default route using the GATEWAY directive, either globally or in interface-specific configuration files. However, in Red Hat Enterprise Linux the use of the global /etc/sysconfig/network file is deprecated, and specifying the gateway should now only be done in per-interface configuration files. In dynamic network environments, where mobile hosts are managed by NetworkManager , gateway information is likely to be interface specific and is best left to be assigned by DHCP . In special cases where it is necessary to influence NetworkManager 's selection of the exit interface to be used to reach a gateway, make use of the DEFROUTE=no command in the ifcfg files for those interfaces which do not lead to the default gateway.

Commands:
Chapter 50. General Updates The TAB key does not expand USDPWD by default When working in CLI in Red Hat Enterprise Linux 6, pressing the TAB key expanded USDPWD/ to the current directory. In Red Hat Enterprise Linux 7, CLI does not have the same behavior. Users can achieve this behavior by putting the following lines into the USDHOME/.bash_profile file: (BZ#1185416) gnome-getting-started-docs-* moved to the Optional channel As of Red Hat Enterprise Linux 7.3, the gnome-getting-started-docs-* packages have been moved from the Base channel to the Optional channel. Consequently, upgrading from an earlier version of Red Hat Enterprise Linux 7 fails, if these packages were previously installed. To work around this problem, uninstall gnome-getting-started-docs-* prior to upgrading to Red Hat Enterprise Linux 7.3. (BZ#1350802) The remote-viewer SPICE client fails to detect newly plugged-in smart card readers The libcacard library in Red Hat Enterprise Linux 7.3 fails to handle USB hot plug events. As a consequence, while the remote-viewer SPICE client is running, the application in some cases fails to detect a USB smart card reader when it is plugged in. To work around the problem, remove the smart card from the reader and reinsert it. (BZ# 1249116 )

Commands:
if ((BASH_VERSINFO[0] >= 4)) && ((BASH_VERSINFO[1] >= 2)); then shopt -s direxpand fi
13.2. Preparing for a Driver Update During Installation If a driver update is necessary and available for your hardware, Red Hat or a trusted third party such as the hardware vendor will typically provide it in the form of an image file in ISO format. Some methods of performing a driver update require you to make the image file available to the installation program, while others require you to use the image file to make a driver update disk: Methods that use the image file itself local hard drive USB flash drive Methods that use a driver update disk produced from an image file CD DVD Choose a method to provide the driver update, and refer to Section 13.2.1, "Preparing to Use a Driver Update Image File" , Section 13.2.2, "Preparing a Driver Disc" , or Section 13.2.3, "Preparing an Initial RAM Disk Update" . Note that you can use a USB storage device either to provide an image file, or as a driver update disk. 13.2.1. Preparing to Use a Driver Update Image File 13.2.1.1. Preparing to use an image file on local storage To make the ISO image file available on local storage, such as a hard drive or USB flash drive, you must first determine whether you want to install the updates automatically or select them manually. For manual installations, copy the file onto the storage device. You can rename the file if you find it helpful to do so, but you must not change the filename extension, which must remain .iso . In the following example, the file is named dd.iso : Figure 13.1. Content of a USB flash drive holding a driver update image file Note that if you use this method, the storage device will contain only a single file. This differs from driver discs on formats such as CD and DVD, which contain many files. The ISO image file contains all of the files that would normally be on a driver disc. Refer to Section 13.3.2, "Let the Installer Prompt You for a Driver Update" and Section 13.3.3, "Use a Boot Option to Specify a Driver Update Disk" to learn how to select the driver update manually during installation. For automatic installations, you will need to extract the ISO to the root directory of the storage device rather than simply copy it. Copying the ISO is only effective for manual installations. You must also change the file system label of the device to OEMDRV . The installation program will then automatically examine it for driver updates and load any that it detects. This behavior is controlled by the dlabel=on boot option, which is enabled by default. Refer to Section 6.3.1, "Let the Installer Find a Driver Update Disk Automatically" .

Commands:
B.41. libcgroup B.41.1. RHSA-2011:0320 - Important: libcgroup security update Updated libcgroup packages that fix two security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The libcgroup packages provide tools and libraries to control and monitor control groups. CVE-2011-1006 A heap-based buffer overflow flaw was found in the way libcgroup converted a list of user-provided controllers for a particular task into an array of strings. A local attacker could use this flaw to escalate their privileges via a specially-crafted list of controllers. CVE-2011-1022 It was discovered that libcgroup did not properly check the origin of Netlink messages. A local attacker could use this flaw to send crafted Netlink messages to the cgrulesengd daemon, causing it to put processes into one or more existing control groups, based on the attacker's choosing, possibly allowing the particular tasks to run with more resources (memory, CPU, etc.) than originally intended. Red Hat would like to thank Nelson Elhage for reporting the CVE-2011-1006 issue. All libcgroup users should upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
1.4.2. Direct Routing Building an LVS setup that uses direct routing provides increased performance benefits compared to other LVS networking topologies. Direct routing allows the real servers to process and route packets directly to a requesting user rather than passing all outgoing packets through the LVS router. Direct routing reduces the possibility of network performance issues by relegating the job of the LVS router to processing incoming packets only. Figure 1.4. LVS Implemented with Direct Routing In the typical direct routing LVS setup, the LVS router receives incoming server requests through the virtual IP (VIP) and uses a scheduling algorithm to route the request to the real servers. The real server processes the request and sends the response directly to the client, bypassing the LVS routers. This method of routing allows for scalability in that real servers can be added without the added burden on the LVS router to route outgoing packets from the real server to the client, which can become a bottleneck under heavy network load. 1.4.2.1. Direct Routing and the ARP Limitation While there are many advantages to using direct routing in LVS, there are limitations as well. The most common issue with LVS via direct routing is with Address Resolution Protocol ( ARP ). In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations. The issue with ARP requests in a direct routing LVS setup is that because a client request to an IP address must be associated with a MAC address for the request to be handled, the virtual IP address of the LVS system must also be associated to a MAC as well. However, since both the LVS router and the real servers all have the same VIP, the ARP request will be broadcast ed to all the machines associated with the VIP. This can cause several problems, such as the VIP being associated directly to one of the real servers and processing requests directly, bypassing the LVS router completely and defeating the purpose of the LVS setup. To solve this issue, ensure that the incoming requests are always sent to the LVS router rather than one of the real servers. This can be done by using either the arptables_jf or the iptables packet filtering tool for the following reasons: The arptables_jf prevents ARP from associating VIPs with real servers. The iptables method completely sidesteps the ARP problem by not configuring VIPs on real servers in the first place. For more information on using arptables or iptables in a direct routing LVS environment, refer to Section 3.2.1, "Direct Routing and arptables_jf " or Section 3.2.2, "Direct Routing and iptables " .

Commands:
Network APIs OpenShift Container Platform 4.15 Reference guide for network APIs Red Hat OpenShift Documentation Team

Commands:
Name: "mysvc", Subsets: [ { Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }, { Addresses: [{"ip": "10.10.3.3"}], Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}] }, ]
Name: "mysvc", Subsets: [ { Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }, { Addresses: [{"ip": "10.10.3.3"}], Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}] }, ]
{ Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }
a: [ 10.10.1.1:8675, 10.10.2.2:8675 ], b: [ 10.10.1.1:309, 10.10.2.2:309 ]
7.112. libxcb 7.112.1. RHBA-2015:1358 - libxcb and libX11 bug fix update Updated libxcb and libX11 packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The libxcb packages provide the X protocol C-language Binding (XCB) library. XCB is a replacement for Xlib featuring a small footprint, latency hiding, direct access to the protocol, improved threading support, and extensibility. The libX11 packages contain the core X11 protocol client library. Bug Fixes BZ# 667789 Previously, the "mute microphone" key in some cases did not work when using Red Hat Enterprise Linux 6. With this update, libX11 properly resolves the key symbol assigned to the "mute microphone" key by the xkeyboard-config keyboard layout files, and the "mute microphone" key now works as expected. BZ# 1206240 , BZ# 1046410 , BZ# 1164296 On 32-bit architectures, an X11 protocol client was under certain circumstances disconnected after processing a large number of X11 requests. With this update, the libxcb library exposes the request sequence number as a 64-bit integer so that libX11 can make use of 64-bit sequence number even on 32-bit systems. As a result, the described failure of the X11 client no longer occurs. Users of libxcb and libX11 are advised to upgrade to these updated packages, which fix these bugs.

Commands:
4.12.3. Disabling ACPI Completely in the grub.conf File The preferred method of disabling ACPI Soft-Off is with chkconfig management ( Section 4.12.1, "Disabling ACPI Soft-Off with chkconfig Management" ). If the preferred method is not effective for your cluster, you can disable ACPI Soft-Off with the BIOS power management ( Section 4.12.2, "Disabling ACPI Soft-Off with the BIOS" ). If neither of those methods is effective for your cluster, you can disable ACPI completely by appending acpi=off to the kernel boot command line in the grub.conf file. Important This method completely disables ACPI; some computers do not boot correctly if ACPI is completely disabled. Use this method only if the other methods are not effective for your cluster. You can disable ACPI completely by editing the grub.conf file of each cluster node as follows: Open /boot/grub/grub.conf with a text editor. Append acpi=off to the kernel boot command line in /boot/grub/grub.conf (see Example 4.2, "Kernel Boot Command Line with acpi=off Appended to It" ). Reboot the node. When the cluster is configured and running, verify that the node turns off immediately when fenced. For information on testing a fence device, see How to test fence devices and fencing configuration in a RHEL 5, 6, or 7 High Availability cluster? . Example 4.2. Kernel Boot Command Line with acpi=off Appended to It In this example, acpi=off has been appended to the kernel boot command line - the line starting with "kernel /vmlinuz-2.6.32-193.el6.x86_64.img".

Commands:
grub.conf generated by anaconda # Note that you do not have to rerun grub after making changes to this file NOTICE: You have a /boot partition. This means that all kernel and initrd paths are relative to /boot/, eg. root (hd0,0) kernel /vmlinuz-version ro root=/dev/mapper/vg_doc01-lv_root initrd /initrd-[generic-]version.img #boot=/dev/hda default=0 timeout=5 serial --unit=0 --speed=115200 terminal --timeout=5 serial console title Red Hat Enterprise Linux Server (2.6.32-193.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-193.el6.x86_64 ro root=/dev/mapper/vg_doc01-lv_root console=ttyS0,115200n8 acpi=off initrd /initramfs-2.6.32-131.0.15.el6.x86_64.img
2.2. Performance Older virtualization versions supported only a single CPU. As a result, virtual machines experienced noticeable performance limitations. This created a long-lasting misconception that virtualization solutions are slow. This is no longer the case. Modern virtualization technology has greatly improved the speed of virtual machines. Benchmarks show that virtual machines can run typical server applications nearly as efficiently as bare-metal systems: Red Hat Enterprise Linux 6.4 and KVM recorded an industry-leading TPC-C benchmark with an IBM DB2 database running in an entirely virtualized x86 environment and delivering 88% of bare-metal performance. Due to resource demands, databases have previously been reserved for bare-metal deployments only. The industry standard SAP Sales and Distribution (SD) Standard Application Benchmark found that Red Hat Enterprise Linux 6.2 and KVM performs at the virtualization efficiency of 85% when compared to a bare-metal system running on identical hardware. Red Hat Enterprise Linux 6.1 and KVM achieved record-setting virtualization performance in the SPECvirt_sc2010 benchmark recorded by the Standard Performance Evaluation Corporation (SPEC), setting the best virtual performance mark of any published SPECvirt result. The SPECvirt_sc2010 metric measures the end-to-end performance of system components in virtualized data center servers. Note For more information on performance tuning for virtualization, see the Red Hat Enterprise Linux 7 Virtualization Tuning and Optimization Guide .

Commands:
Chapter 2. Key Components A complete JBoss Data Virtualization solution consists of the following: The Server The server is positioned between business applications and one or more data sources. It coordinates integration of these data sources so they can be accessed by the business applications at runtime. Design Tools Various design tools are available to assist users in setting up JBoss Data Virtualization for a particular data integration solution. Administration Tools Various management tools are available for administrators to configure and monitor JBoss Data Virtualization.

Commands:
Chapter 19. Tuning for Performance This chapter provides information on configuring Red Hat Gluster Storage and explains clear and simple activities that can improve system performance. 19.1. Disk Configuration Red Hat Gluster Storage supports JBOD (Just a Bunch of Disks) and hardware RAID storage. 19.1.1. Hardware RAID The RAID levels that are most commonly recommended are RAID 6 and RAID 10. RAID 6 provides better space efficiency, good read performance and good performance for sequential writes to large files. When configured across 12 disks, RAID 6 can provide ~40% more storage space in comparison to RAID 10, which has a 50% reduction in capacity. However, RAID 6 performance for small file writes and random writes tends to be lower than RAID 10. If the workload is strictly small files, then RAID 10 is the optimal configuration. An important parameter in hardware RAID configuration is the stripe unit size. With thin provisioned disks, the choice of RAID stripe unit size is closely related to the choice of thin-provisioning chunk size. For RAID 10, a stripe unit size of 256 KiB is recommended. For RAID 6, the stripe unit size must be chosen such that the full stripe size (stripe unit * number of data disks) is between 1 MiB and 2 MiB, preferably in the lower end of the range. Hardware RAID controllers usually allow stripe unit sizes that are a power of 2. For RAID 6 with 12 disks (10 data disks), the recommended stripe unit size is 128KiB. 19.1.2. JBOD In the JBOD configuration, physical disks are not aggregated into RAID devices, but are visible as separate disks to the operating system. This simplifies system configuration by not requiring a hardware RAID controller. If disks on the system are connected through a hardware RAID controller, refer to the RAID controller documentation on how to create a JBOD configuration; typically, JBOD is realized by exposing raw drives to the operating system using a pass-through mode. In the JBOD configuration, a single physical disk serves as storage for a Red Hat Gluster Storage brick. JBOD configurations support up to 36 disks per node with dispersed volumes and three-way replication.

Commands: