mtpti5iD/redhat-docs_dataset huggingface dataset:
C.4. Failure Recovery and Independent Subtrees In most enterprise environments, the normal course of action for failure recovery of a service is to restart the entire service if any component in the service fails. For example, in Example C.6, "Service foo Normal Failure Recovery" , if any of the scripts defined in this service fail, the normal course of action is to restart (or relocate or disable, according to the service recovery policy) the service. However, in some circumstances certain parts of a service may be considered non-critical; it may be necessary to restart only part of the service in place before attempting normal recovery. To accomplish that, you can use the __independent_subtree attribute. For example, in Example C.7, "Service foo Failure Recovery with __independent_subtree Attribute" , the __independent_subtree attribute is used to accomplish the following actions: If script:script_one fails, restart script:script_one, script:script_two, and script:script_three. If script:script_two fails, restart just script:script_two. If script:script_three fails, restart script:script_one, script:script_two, and script:script_three. If script:script_four fails, restart the whole service. Example C.6. Service foo Normal Failure Recovery Example C.7. Service foo Failure Recovery with __independent_subtree Attribute In some circumstances, if a component of a service fails you may want to disable only that component without disabling the entire service, to avoid affecting other services that use other components of that service. As of the Red Hat Enterprise Linux 6.1 release, you can accomplish that by using the __independent_subtree="2" attribute, which designates the independent subtree as non-critical. Note You may only use the non-critical flag on singly-referenced resources. The non-critical flag works with all resources at all levels of the resource tree, but should not be used at the top level when defining services or virtual machines. As of the Red Hat Enterprise Linux 6.1 release, you can set maximum restart and restart expirations on a per-node basis in the resource tree for independent subtrees. To set these thresholds, you can use the following attributes: __max_restarts configures the maximum number of tolerated restarts prior to giving up. __restart_expire_time configures the amount of time, in seconds, after which a restart is no longer attempted.

Commands:
<service name="foo"> <script name="script_one" ...> <script name="script_two" .../> </script> <script name="script_three" .../> </service>
<service name="foo"> <script name="script_one" __independent_subtree="1" ...> <script name="script_two" __independent_subtree="1" .../> <script name="script_three" .../> </script> <script name="script_four" .../> </service>
Chapter 1. Operators overview Operators are among the most important components of OpenShift Dedicated. They are the preferred method of packaging, deploying, and managing services on the control plane. They can also provide advantages to applications that users run. Operators integrate with Kubernetes APIs and CLI tools such as kubectl and the OpenShift CLI ( oc ). They provide the means of monitoring applications, performing health checks, managing over-the-air (OTA) updates, and ensuring that applications remain in your specified state. Operators are designed specifically for Kubernetes-native applications to implement and automate common Day 1 operations, such as installation and configuration. Operators can also automate Day 2 operations, such as autoscaling up or down and creating backups. All of these activities are directed by a piece of software running on your cluster. While both follow similar Operator concepts and goals, Operators in OpenShift Dedicated are managed by two different systems, depending on their purpose: Cluster Operators Managed by the Cluster Version Operator (CVO) and installed by default to perform cluster functions. Optional add-on Operators Managed by Operator Lifecycle Manager (OLM) and can be made accessible for users to run in their applications. Also known as OLM-based Operators . 1.1. For developers As an Operator author, you can perform the following development tasks for OLM-based Operators: Install Operator SDK CLI . Create Go-based Operators , Ansible-based Operators , and Helm-based Operators . Use Operator SDK to build, test, and deploy an Operator . Create an application from an installed Operator through the web console . 1.2. For administrators As an administrator with the dedicated-admin role, you can perform the following Operator tasks: Manage custom catalogs . Install an Operator from OperatorHub . View Operator status . Manage Operator conditions . Upgrade installed Operators . Delete installed Operators . Configure proxy support . 1.3. steps To understand more about Operators, see What are Operators?

Commands:
Chapter 15. catalog This chapter describes the commands under the catalog command. 15.1. catalog list List services in the service catalog Usage: Table 15.1. Optional Arguments Value Summary -h, --help Show this help message and exit Table 15.2. Output Formatters Value Summary -f {csv,json,table,value,yaml}, --format {csv,json,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated --sort-column SORT_COLUMN Specify the column(s) to sort the data (columns specified first have a priority, non-existing columns are ignored), can be repeated Table 15.3. CSV Formatter Value Summary --quote {all,minimal,none,nonnumeric} When to include quotes, defaults to nonnumeric Table 15.4. JSON Formatter Value Summary --noindent Whether to disable indenting the json Table 15.5. Table Formatter Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show. 15.2. catalog show Display service catalog details Usage: Table 15.6. Positional Arguments Value Summary <service> Service to display (type or name) Table 15.7. Optional Arguments Value Summary -h, --help Show this help message and exit Table 15.8. Output Formatters Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated Table 15.9. JSON Formatter Value Summary --noindent Whether to disable indenting the json Table 15.10. Shell Formatter Value Summary --prefix PREFIX Add a prefix to all variable names Table 15.11. Table Formatter Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack catalog list [-h] [-f {csv,json,table,value,yaml}] [-c COLUMN] [--quote {all,minimal,none,nonnumeric}] [--noindent] [--max-width <integer>] [--fit-width] [--print-empty] [--sort-column SORT_COLUMN]
openstack catalog show [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] <service>
Chapter 1. The LVM Logical Volume Manager This chapter provides a high-level overview of the components of the Logical Volume Manager (LVM). 1.1. Logical Volumes Volume management creates a layer of abstraction over physical storage, allowing you to create logical storage volumes. This provides much greater flexibility in a number of ways than using physical storage directly. A logical volume provides storage virtualization. With a logical volume, you are not restricted to physical disk sizes. In addition, the hardware storage configuration is hidden from the software so it can be resized and moved without stopping applications or unmounting file systems. This can reduce operational costs. Logical volumes provide the following advantages over using physical storage directly: Flexible capacity When using logical volumes, file systems can extend across multiple disks, since you can aggregate disks and partitions into a single logical volume. Resizeable storage pools You can extend logical volumes or reduce logical volumes in size with simple software commands, without reformatting and repartitioning the underlying disk devices. Online data relocation To deploy newer, faster, or more resilient storage subsystems, you can move data while your system is active. Data can be rearranged on disks while the disks are in use. For example, you can empty a hot-swappable disk before removing it. Convenient device naming Logical storage volumes can be managed in user-defined groups, which you can name according to your convenience. Disk striping You can create a logical volume that stripes data across two or more disks. This can dramatically increase throughput. Mirroring volumes Logical volumes provide a convenient way to configure a mirror for your data. Volume Snapshots Using logical volumes, you can take device snapshots for consistent backups or to test the effect of changes without affecting the real data. The implementation of these features in LVM is described in the remainder of this document.

Commands:
20.16.9.16. Modifying virtual link state This element provides means of setting state of the virtual network link. Possible values for attribute state are up and down . If down is specified as the value, the interface behaves as if it had the network cable disconnected. Default behavior if this element is unspecified is to have the link state up . To specify the virtual link state configuration settings, use a management tool to make the following changes to the domain XML: ... <devices> <interface type='network'> <source network='default'/> <target dev='vnet0'/> <link state='down'/> </interface> <devices> ... Figure 20.53. Modifying virtual link state

Commands:
<devices> <interface type='network'> <source network='default'/> <target dev='vnet0'/> <link state='down'/> </interface> <devices>
Chapter 1. Prerequisites Red Hat Enterprise Linux (RHEL) 9 To obtain the latest version of Red Hat Enterprise Linux (RHEL) 9, see Downlad Red Hat Enterprise Linux . For installation instructions, see the Product Documentation for Red Hat Enterprise Linux 8 . An active subscription to Red Hat Two or more virtual CPUs 4 GB or more of RAM Approximately 30 GB of disk space on your test system, which can be broken down as follows: Approximately 10 GB of disk space for the Red Hat Enterprise Linux (RHEL) operating system. Approximately 10 GB of disk space for Docker storage for running three containers. Approximately 10 GB of disk space for Red Hat Quay local storage. Note CEPH or other local storage might require more memory. More information on sizing can be found at Quay 3.x Sizing Guidlines . 1.1. Installing Podman This document uses Podman for creating and deploying containers. For more information on Podman and related technologies, see Building, running, and managing Linux containers on Red Hat Enterprise Linux 9 . Important If you do not have Podman installed on your system, the use of equivalent Docker commands might be possible, however this is not recommended. Docker has not been tested with Red Hat Quay 3.10, and will be deprecated in a future release. Podman is recommended for highly available, production quality deployments of Red Hat Quay 3.10. Use the following procedure to install Podman. Procedure Enter the following command to install Podman: USD sudo yum install -y podman Alternatively, you can install the container-tools module, which pulls in the full set of container software packages: USD sudo yum module install -y container-tools

Commands:
sudo yum install -y podman
sudo yum module install -y container-tools
Chapter 2. An overview of OpenShift Data Foundation architecture Red Hat OpenShift Data Foundation provides services for, and can run internally from Red Hat OpenShift Container Platform. Figure 2.1. Red Hat OpenShift Data Foundation architecture Red Hat OpenShift Data Foundation supports deployment into Red Hat OpenShift Container Platform clusters deployed on Installer Provisioned Infrastructure or User Provisioned Infrastructure. For details about these two approaches, see OpenShift Container Platform - Installation process . To know more about interoperability of components for the Red Hat OpenShift Data Foundation and Red Hat OpenShift Container Platform, see the interoperability matrix . For information about the architecture and lifecycle of OpenShift Container Platform, see OpenShift Container Platform architecture .

Commands:
Appendix I. Revision History Note that revision numbers relate to the edition of this manual, not to version numbers of Red Hat Enterprise Linux. Revision History Revision 1.0-138 Tue Mar 14 2017 Petr Bokoc Asynchronous update. Revision 1.0-137 Tue Mar 14 2017 Petr Bokoc Red Hat Enterprise Linux 6.9 General Availability release. Revision 1.0-131 Tue Mar 11 2016 Clayton Spicer Red Hat Enterprise Linux 6.8 GA release. Revision 1.0-127 Fri 10 Jul 2015 Petr Bokoc Red Hat Enterprise Linux 6.7 GA release Revision 1.0-112 Wed Oct 08 2014 Petr Bokoc Red Hat Enterprise Linux 6.6 GA release Revision 1.0-102 Thu Nov 07 2013 Petr Bokoc Red Hat Enterprise Linux 6.5 GA release Revision 1.0-96 Tue Feb 19 2013 Jack Reed Second version for Red Hat Enterprise Linux 6.4 GA release Revision 1.0-95 Sun Feb 17 2013 Jack Reed Red Hat Enterprise Linux 6.4 GA release Revision 1.0-41 Thu May 19 2011 Rudiger Landmann Red Hat Enterprise Linux 6.1 GA release Revision 1.0-0 Wed Aug 25 2010 Rudiger Landmann Red Hat Enterprise Linux 6.0 GA release

Commands:
Introduction This document provides information about installing, configuring and managing Red Hat High Availability Add-On components. Red Hat High Availability Add-On components allow you to connect a group of computers (called nodes or members ) to work together as a cluster. In this document, the use of the word cluster or clusters is used to refer to a group of computers running the Red Hat High Availability Add-On. The audience of this document should have advanced working knowledge of Red Hat Enterprise Linux and understand the concepts of clusters, storage, and server computing. For more information about Red Hat Enterprise Linux 6, see the following resources: Red Hat Enterprise Linux Installation Guide - Provides information regarding installation of Red Hat Enterprise Linux 6. Red Hat Enterprise Linux Deployment Guide - Provides information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 6. For more information about the High Availability Add-On and related products for Red Hat Enterprise Linux 6, see the following resources: High Availability Add-On Overview - Provides a high-level overview of the Red Hat High Availability Add-On. Logical Volume Manager Administration - Provides a description of the Logical Volume Manager (LVM), including information on running LVM in a clustered environment. Global File System 2: Configuration and Administration - Provides information about installing, configuring, and maintaining Red Hat GFS2 (Red Hat Global File System 2), which is included in the Resilient Storage Add-On. DM Multipath - Provides information about using the Device-Mapper Multipath feature of Red Hat Enterprise Linux 6. Load Balancer Administration - Provides information on configuring high-performance systems and services with the Load Balancer Add-On, a set of integrated software components that provide Linux Virtual Servers (LVS) for balancing IP load across a set of real servers. Release Notes - Provides information about the current release of Red Hat products. Red Hat documents are available in HTML, PDF, and RPM versions online at https://access.redhat.com/documentation/en/red-hat-enterprise-linux/ . 1. Feedback If you spot a typo, or if you have thought of a way to make this manual better, we would love to hear from you. Please submit a report in Bugzilla: http://bugzilla.redhat.com/bugzilla/ . File the bug against the product Red Hat Enterprise Linux 6 and the component doc-Cluster_Administration . Be sure to mention the manual identifier: By mentioning this manual's identifier, we know exactly which version of the guide you have. If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, include the section number and some of the surrounding text so we can find it easily.

Commands:
Cluster_Administration(EN)-6 (2017-3-07T16:26)
7.2.2. Configuration changes for Windows virtual machines Warning Before converting Windows virtual machines, ensure that the libguestfs-winsupport and virtio-win packages are installed on the host running virt-v2v . These packages provide support for NTFS and Windows paravirtualized block and network drivers. If you attempt to convert a virtual machine using NTFS without the libguestfs-winsupport package installed, the conversion will fail. If you attempt to convert a virtual machine running Windows without the virtio-win package installed, the conversion will fail giving an error message concerning missing files. See Section 4.3.1.2, "Preparing to convert a virtual machine running Windows" for details. virt-v2v can convert virtual machines running Windows XP, Windows Vista, Windows 7, Windows Server 2003 and Windows Server 2008. The conversion process for virtual machines running Windows is slightly to different to the process for virtual machines running Linux. Windows virtual machine images are converted as follows: virt-v2v installs VirtIO block drivers. virt-v2v installs the CDUpgrader utility. virt-v2v copies VirtIO block and network drivers to %SystemRoot%\Drivers\VirtIO . The virtio-win package does not include network drivers for Windows 7 and Windows XP. For those operating systems, the rtl8139 network drivers are used. rtl8139 support must be already available in the guest virtual machine. virt-v2v adds %SystemRoot%\Drivers\VirtIO to DevicePath , meaning this directory is automatically searched for drivers when a new device is detected. virt-v2v makes registry changes to include the VirtIO block drivers in the CriticalDeviceDatabase section of the registry, and ensure the CDUpgrader service is started at the boot. At this point, virt-v2v has completed the conversion. The converted virtual machine is now fully functional, and the conversion is complete for output to KVM managed by libvirt. If the virtual machine is being converted for output to Red Hat Enterprise Virtualization, the Red Hat Enterprise Virtualization Manager will perform additional steps to complete the conversion: The virtual machine is imported and run on the Manager. See the Red Hat Enterprise Virtualization Administration Guide for details. Important The first boot stage can take several minutes to run, and must not be interrupted. It will run automatically without any administrator intervention other than starting the virtual machine. To ensure the process is not interrupted, no user should log in to the virtual machine until it has quiesced. You can check for this in the Manager GUI. If the guest tools ISO has been uploaded to the Manager, as detailed in Section 4.3.1.2, "Preparing to convert a virtual machine running Windows" , the Manager attaches the guest tools CD to the virtual machine. CDUpgrader detects the guest tools ISO and installs all the VirtIO drivers from it, including additional tools that are not included in virtio-win . The VirtIO drivers are reinstalled if the drivers in the guest tools ISO are newer than the ones previously installed from virtio-win . This ensures that the tools are kept up to date.

Commands:
Appendix D. Enabling FIPS in Red Hat Virtualization You can set up Red Hat Virtualization to be compliant with the Federal Information Processing Standard (FIPS), specifically FIPS 140-2. You can enable FIPS mode selectively, on specific virtual machines, bare metal machines, or across your entire environment, based on your organization's FIPS compliance requirements. You can create a FIPS-enabled bare metal machine in RHV 4.4 by either installing the operating system in FIPS mode, or by switching the system into FIPS mode after installing the operating system. However, you must switch to FIPS mode before installing and configuring Red Hat Virtualization to avoid introducing system conflicts. Important Red Hat recommends installing RHEL 8 with FIPS mode enabled as opposed to enabling FIPS mode later. Enabling FIPS mode during the installation ensures that the system generates all keys with FIPS-approved algorithms and continuous monitoring tests in place. You enable FIPS first on each bare metal machine, and then in the Manager. Enabling FIPS in a self-hosted engine Enabling FIPS in RHEL hosts and the standalone Manager D.1. Enabling FIPS in a self-hosted engine You can enable FIPS in a self-hosted engine during deployment when using the command-line. Procedure Start the self-hosted engine deployment script. See Installing Red Hat Virtualization as a self-hosted engine using the command line . When the deployment script prompts Do you want to enable FIPS? , enter Yes Verification Verify that FIPS is enabled by entering the command fips-mode-setup --check on the host. The command should return FIPS mode is enabled : # fips-mode-setup --check FIPS mode is enabled.

Commands:
fips-mode-setup --check FIPS mode is enabled.
Chapter 59. Security scap-security-guide example kickstart files for Red Hat Enterprise Linux 6 are not recommended for use The Red Hat Enterprise Linux 6 example kickstart files, which are included in the scap-security-guide package for Red Hat Enterprise Linux 7, install the latest version of the scap-security-guide package directly from the upstream repository, which means that this version has not been checked by the Red Hat Quality Engineering team. To work around this problem, use the corrected Red Hat Enterprise Linux 6 example kickstart files from the scap-security-guide package that is included in the current Red Hat Enterprise Linux 6 release, or alternatively, manually change the %post section in the kickstart file. Note that the Red Hat Enterprise Linux 7 example kickstart files are not affected by this problem. (BZ# 1378489 ) The openscap packages do not install atomic as a dependency The OpenSCAP suite enables integration of the Security Content Automation Protocol (SCAP) line of standards. The current version adds the ability to scan containers using the atomic scan and oscap-docker commands. However, when you install only the openscap , openscap-utils , and openscap-scanner packages, the atomic package is not installed by default. As a consequence, any container scan command fails with an error message. To work around this problem, install the atomic package by running the yum install atomic command as root. (BZ#1356547) CIL does not have a separate module statement The new SELinux userspace uses SELinux Common Intermediate Language (CIL) in the module store. CIL treats files as modules and does not have a separate module statement, the module is named after the file name. As a consequence, this can cause confusion when a policy module has a name that is not the same as its base filename, and the semodule -l command does not show the module version. Additionaly, semodule -l does not show disabled modules. To work around this problem, list all modules using the semodule --l=full command. (BZ#1345825)

Commands: