mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Red Hat Ceph Storage Red Hat Ceph Storage is a scalable, open, software-defined storage platform that combines an enterprise-hardened version of the Ceph storage system, with a Ceph management platform, deployment utilities, and support services. Red Hat Ceph Storage is designed for cloud infrastructure and web-scale object storage. Red Hat Ceph Storage clusters consist of the following types of nodes: Ceph Monitor Each Ceph Monitor node runs the ceph-mon daemon, which maintains a master copy of the storage cluster map. The storage cluster map includes the storage cluster topology. A client connecting to the Ceph storage cluster retrieves the current copy of the storage cluster map from the Ceph Monitor, which enables the client to read from and write data to the storage cluster. Important The storage cluster can run with only one Ceph Monitor; however, to ensure high availability in a production storage cluster, Red Hat will only support deployments with at least three Ceph Monitor nodes. Red Hat recommends deploying a total of 5 Ceph Monitors for storage clusters exceeding 750 Ceph OSDs. Ceph Manager The Ceph Manager daemon, ceph-mgr , co-exists with the Ceph Monitor daemons running on Ceph Monitor nodes to provide additional services. The Ceph Manager provides an interface for other monitoring and management systems using Ceph Manager modules. Running the Ceph Manager daemons is a requirement for normal storage cluster operations. Ceph OSD Each Ceph Object Storage Device (OSD) node runs the ceph-osd daemon, which interacts with logical disks attached to the node. The storage cluster stores data on these Ceph OSD nodes. Ceph can run with very few OSD nodes, of which the default is three, but production storage clusters realize better performance beginning at modest scales. For example, 50 Ceph OSDs in a storage cluster. Ideally, a Ceph storage cluster has multiple OSD nodes, allowing for the possibility to isolate failure domains by configuring the CRUSH map accordingly. Ceph MDS Each Ceph Metadata Server (MDS) node runs the ceph-mds daemon, which manages metadata related to files stored on the Ceph File System (CephFS). The Ceph MDS daemon also coordinates access to the shared storage cluster. Ceph Object Gateway Ceph Object Gateway node runs the ceph-radosgw daemon, and is an object storage interface built on top of librados to provide applications with a RESTful access point to the Ceph storage cluster. The Ceph Object Gateway supports two interfaces: S3 Provides object storage functionality with an interface that is compatible with a large subset of the Amazon S3 RESTful API. Swift Provides object storage functionality with an interface that is compatible with a large subset of the OpenStack Swift API. Additional Resources For details on the Ceph architecture, see the Red Hat Ceph Storage Architecture Guide . For the minimum hardware recommendations, see the Red Hat Ceph Storage Hardware Selection Guide .

Commands:
5.5. Changing the Format of User Names Displayed by SSSD By default, SSSD uses the user_name@domain_name format when displaying user names. Before you change the format, see Section 5.2.1.9, "Supported User Name Formats" to learn about the reason of this default value. To configure that SSSD displays only the user name without domain: Add the following entry to the domain's section in the /etc/sssd/sssd.conf file: Restart SSSD:

Commands:
full_name_format = %1USDs
systemctl restart sssd
3.7. XML Document Formatting The PROP_XML_FORMAT execution property, defined in org.teiid.jdbc.ExecutionProperties , can be set using the SET statement to modify the way that XML documents are formatted from XML document models. The following valid values are also defined: XML_TREE_FORMAT XML_TREE_FORMAT (defined as Tree) returns a version of the XML formatted for display. The XML will use line breaks and tabs as appropriate to format the XML as a tree. This format is slower due to the formatting time and the larger document size. XML_COMPACT_FORMAT XML_COMPACT_FORMAT (defined as Compact) returns a version of the XML formatted for optimal performance. The XML is a single long string without any unnecessary white space. Important If the XML_COMPACT_FORMAT execution property is not set, the formatting flag of the XML document in the original model is honored. This may produce either the tree or compact form of the document depending on the document setting.

Commands:
Chapter 3. Providing feedback on OpenShift Container Platform documentation To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account. Procedure Click one of the following links: To create a Jira issue for OpenShift Container Platform To create a Jira issue for OpenShift Virtualization Enter a brief description of the issue in the Summary . Provide a detailed description of the issue or enhancement in the Description . Include a URL to where the issue occurs in the documentation. Click Create to create the issue.

Commands:
Chapter 4. Setting up the test environment The first step towards certifying your product is setting up the environment where you can run the tests. The test environment consists of one system: System 1: Acts as a host under test (HUT) 4.1. Setting up the host under test A system on which the product that needs certification is installed or configured is referred to as the host under test (HUT). Prerequisites The HUT has RHEL version 8 or 9 installed. For convenience, Red Hat provides kickstart files to install the HUT's operating system. Follow the instructions in the file that is appropriate for your system before launching the installation process. Procedure Configure the Red Hat Certification repository: Use your RHN credentials to register your system using Red Hat Subscription Management: Display the list of available subscriptions for your system: Search for the subscription which provides the Red Hat Certification (for RHEL Server) repository and make a note of the subscription and its Pool ID. Attach the subscription to your system. Replace the pool_ID with the Pool ID of the subscription. Note You don't have to attach the subscription to your system, if you enable the option Simple content access for Red Hat Subscription Management . For more details, see How do I enable Simple Content Access for Red Hat Subscription Management? Subscribe to the Red Hat Certification channel: On RHEL 8: Replace HOSTTYPE with the system architecture. To find out the system architecture, run Example: On RHEL 9: Replace HOSTTYPE with the system architecture. To find out the system architecture, run Example: Install cloud test suite package: steps See Chapter 5, Downloading the test plan from Red Hat Certification Portal

Commands:
subscription-manager register
subscription-manager list --available*
subscription-manager attach --pool= <pool_ID >
subscription-manager repos --enable=cert-1-for-rhel-8- <HOSTTYPE> -rpms
uname -m
subscription-manager repos --enable=cert-1-for-rhel-8-x86_64-rpms
subscription-manager repos --enable=cert-1-for-rhel-9- <HOSTTYPE> -rpms
uname -m
subscription-manager repos --enable=cert-1-for-rhel-9-x86_64-rpms
yum install redhat-certification-cloud-sap
2.3.3. Mirrored Logical Volumes A mirror maintains identical copies of data on different devices. When data is written to one device, it is written to a second device as well, mirroring the data. This provides protection for device failures. When one leg of a mirror fails, the logical volume becomes a linear volume and can still be accessed. LVM supports mirrored volumes. When you create a mirrored logical volume, LVM ensures that data written to an underlying physical volume is mirrored onto a separate physical volume. With LVM, you can create mirrored logical volumes with multiple mirrors. An LVM mirror divides the device being copied into regions that are typically 512KB in size. LVM maintains a small log which it uses to keep track of which regions are in sync with the mirror or mirrors. This log can be kept on disk, which will keep it persistent across reboots, or it can be maintained in memory. Figure 2.6, "Mirrored Logical Volume" shows a mirrored logical volume with one mirror. In this configuration, the log is maintained on disk. Figure 2.6. Mirrored Logical Volume For information on creating and modifying mirrors, see Section 4.4.1.3, "Creating Mirrored Volumes" .

Commands:
21.10. Enabling Intel VT-x and AMD-V Virtualization Hardware Extensions in BIOS Note To expand your expertise, you might also be interested in the Red Hat Virtualization (RH318) training course. This section describes how to identify hardware virtualization extensions and enable them in your BIOS if they are disabled. The Intel VT-x extensions can be disabled in the BIOS. Certain laptop vendors have disabled the Intel VT-x extensions by default in their CPUs. The virtualization extensions cannot be disabled in the BIOS for AMD-V. Refer to the following section for instructions on enabling disabled virtualization extensions. Verify the virtualization extensions are enabled in BIOS. The BIOS settings for Intel VT or AMD-V are usually in the Chipset or Processor menus. The menu names may vary from this guide, the virtualization extension settings may be found in Security Settings or other non standard menu names. Procedure 21.3. Enabling virtualization extensions in BIOS Reboot the computer and open the system's BIOS menu. This can usually be done by pressing the delete key, the F1 key or Alt and F4 keys depending on the system. Enabling the virtualization extensions in BIOS Note Many of the steps below may vary depending on your motherboard, processor type, chipset and OEM. Refer to your system's accompanying documentation for the correct information on configuring your system. Open the Processor submenu The processor settings menu may be hidden in the Chipset , Advanced CPU Configuration or Northbridge . Enable Intel Virtualization Technology (also known as Intel VT-x). AMD-V extensions cannot be disabled in the BIOS and should already be enabled. The virtualization extensions may be labeled Virtualization Extensions , Vanderpool or various other names depending on the OEM and system BIOS. Enable Intel VT-d or AMD IOMMU, if the options are available. Intel VT-d and AMD IOMMU are used for PCI device assignment. Select Save & Exit . Reboot the machine. When the machine has booted, run cat /proc/cpuinfo |grep -E "vmx|svm" . Specifying --color is optional, but useful if you want the search term highlighted. If the command outputs, the virtualization extensions are now enabled. If there is no output your system may not have the virtualization extensions or the correct BIOS setting enabled.

Commands:
5.3.15. Moving a Volume Group to Another System You can move an entire LVM volume group to another system. It is recommended that you use the vgexport and vgimport commands when you do this. Note As of Red Hat Enterprise Linux 6.5, you can use the --force argument of the vgimport command. This allows you to import volume groups that are missing physical volumes and subsequently run the vgreduce --removemissing command. The vgexport command makes an inactive volume group inaccessible to the system, which allows you to detach its physical volumes. The vgimport command makes a volume group accessible to a machine again after the vgexport command has made it inactive. To move a volume group form one system to another, perform the following steps: Make sure that no users are accessing files on the active volumes in the volume group, then unmount the logical volumes. Use the -a n argument of the vgchange command to mark the volume group as inactive, which prevents any further activity on the volume group. Use the vgexport command to export the volume group. This prevents it from being accessed by the system from which you are removing it. After you export the volume group, the physical volume will show up as being in an exported volume group when you execute the pvscan command, as in the following example. When the system is shut down, you can unplug the disks that constitute the volume group and connect them to the new system. When the disks are plugged into the new system, use the vgimport command to import the volume group, making it accessible to the new system. Activate the volume group with the -a y argument of the vgchange command. Mount the file system to make it available for use.

Commands:
pvscan PV /dev/sda1 is in exported VG myvg [17.15 GB / 7.15 GB free] PV /dev/sdc1 is in exported VG myvg [17.15 GB / 15.15 GB free] PV /dev/sdd1 is in exported VG myvg [17.15 GB / 15.15 GB free]
7.4. Editing a Template Once a template has been created, its properties can be edited. Because a template is a copy of a virtual machine, the options available when editing a template are identical to those in the Edit Virtual Machine window. Procedure Click Compute Templates and select a template. Click Edit . Change the necessary properties. Click Show Advanced Options and edit the template's settings as required. The settings that appear in the Edit Template window are identical to those in the Edit Virtual Machine window, but with the relevant fields only. See Explanation of Settings in the New Virtual Machine and Edit Virtual Machine Windows for details. Click OK .

Commands:
10.2. Quorum Administration Commands (Red Hat Enterprise Linux 7.3 and Later) Once a cluster is running, you can enter the following cluster quorum commands. The following command shows the quorum configuration. The following command shows the quorum runtime status. If you take nodes out of a cluster for a long period of time and the loss of those nodes would cause quorum loss, you can change the value of the expected_votes parameter for the live cluster with the pcs quorum expected-votes command. This allows the cluster to continue operation when it does not have quorum. Warning Changing the expected votes in a live cluster should be done with extreme caution. If less than 50% of the cluster is running because you have manually changed the expected votes, then the other nodes in the cluster could be started separately and run cluster services, causing data corruption and other unexpected results. If you change this value, you should ensure that the wait_for_all parameter is enabled. The following command sets the expected votes in the live cluster to the specified value. This affects the live cluster only and does not change the configuration file; the value of expected_votes is reset to the value in the configuration file in the event of a reload.

Commands:
pcs quorum [config]
pcs quorum status
pcs quorum expected-votes votes
8.160. openssl 8.160.1. RHBA-2014:1525 - openssl bug fix and enhancement update Updated openssl packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL), Transport Layer Security (TLS), and Datagram Transport Layer Security (DTLS) protocols, as well as a full-strength, general purpose cryptography library. Bug Fixes BZ# 1057520 Previously, cipher suites based on the single-DES and RC2 algorithms were on the default list of cipher suites used by the SSL or TLS client and by the server in the OpenSSL library. This allowed for suboptimal cipher suites to be negotiated between the OpenSSL client or server and a third party client or server. In addition, a higher amount of supported cipher suites in the TLS ClientHello request impaired the inter-operability of the OpenSSL TLS client. This update removes single-DES-based and RC2-based cipher suites from the default list of cipher suites, improving the security and compatibility of the OpenSSL TLS client. BZ# 1056608 Cipher suites based on the Triple DES (3DES) algorithm had their bit strengths erroneously set to 168 bits when running under the SSL or TLS protocols. As a consequence, they were incorrectly sorted before cipher suites based on the AES-128 algorithm. This update sets the bit strength of 3DES-based cipher suites to 128 bits, and they will now be sorted after AES-128-based cipher suites as expected. BZ# 1090952 In TLS client applications that use the SSLv2 protocol, the TLS extension giving the list of supported Elliptic Curve Cryptography (ECC)-based cipher suites could not be sent. This caused a TLS connection to a server which used an ECC-based cipher suite not supported by the OpenSSL client to abort. With this update, the ECC-based cipher suites are not sent in the SSLv2 ClientHello request, and TLS connections are no longer aborted in the above circumstances. BZ# 1119800 The TLS extensions that were sent in the Datagram TLS (DTLS) ClientHello requests did not previously contain the list of the supported ECC-based cipher suites. As a consequence, the DTLS connections to servers using ECC cipher suites not supported by the OpenSSL client were aborted. With this update, the ECC-based cipher suite list is properly sent in the DTLS ClientHello requests, and DTLS connections are no longer aborted in the above circumstances. In addition, this update adds the following Enhancements BZ# 1002926 , BZ# 1039105 , BZ# 1002930 , BZ# 1015056 The openssl packages have been enhanced to allow for FIPS-140-2 validation of the OpenSSL library as a FIPS cryptographic module. BZ# 1057715 When connecting to a server using ECDHE-based or DHE-based cipher suites, the s_client utility now reports the size of ECDHE and DHE parameters selected by the server. This allows for easy verification whether the used configuration set is secure. Users of openssl are advised to upgrade to these updated packages, which fix these bugs and add these enhancements. For the update to take effect, all services linked to the OpenSSL library must be restarted, or the system rebooted.

Commands:
Chapter 7. Using a Red Hat Image Builder image for provisioning In Satellite, you can enable integration with the RHEL web console to perform actions and monitor your hosts. Using the RHEL web console, you can access Red Hat Image Builder and build images that you can then upload to an HTTP server and use this image to provision hosts. When you configure Satellite for image provisioning, Anaconda installer partitions disks, downloads and mounts the image and copies files over to a host. The preferred image type is TAR. Ensure that your blueprint to build the TAR image includes a kernel package. For more information about integrating the RHEL web console with Satellite, see Host management and monitoring using the RHEL web console in Managing hosts . Prerequisites An existing TAR image created using Red Hat Image Builder. Procedure On Satellite, create a custom product, add a custom file repository to this product, and upload the image to the repository. For more information, see Importing Individual ISO Images and Files in Managing content . In the Satellite web UI, navigate to Configure > Host Groups , and select the host group that you want to use. Click the Parameters tab, and then click Add Parameter . In the Name field, enter kickstart_liveimg . From the Type list, select string . In the Value field, enter the absolute path or a relative path in the following format custom/ product / repository / image_name that points to the exact location where you store the image. Click Submit to save your changes. You can use this image for bare-metal provisioning and provisioning using a compute resource. For more information about bare-metal provisioning, see Chapter 4, Using PXE to provision hosts . For more information about provisioning with different compute resources, see the relevant chapter for the compute resource that you want to use.

Commands:
5.256. PyQt4 5.256.1. RHBA-2012:1241 - PyQt4 bug fix update Updated PyQt4 packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The PyQt4 packages contain python bindings for Qt4. Bug Fixes BZ# 757411 Prior to this update, the PyQt4 utility did not contain the deleteResource method of PyQt4.QtNetwork.QNetworkAccessManager. This update modifies the underlying code to include the missing qnetwork-deleteResource method. BZ# 821061 Prior to this update, the PyQt4 utility did not contain the QMenuBar.setCornerWidget method. This update modifies the underlying code to include the missing qmenubar-cornerWidget method. All users of PyQt4 are advised to upgrade to these updated packages, which fix these bugs.

Commands:
8.15. Additional Resources Installed Documentation teamd(8) man page - Describes the teamd service. teamdctl(8) man page - Describes the teamd control tool. teamd.conf(5) man page - Describes the teamd configuration file. teamnl(8) man page - Describes the teamd Netlink library. bond2team(1) man page - Describes a tool to convert bonding options to team. Online Documentation http://www.w3schools.com/js/js_json_syntax.asp An explanation of JSON syntax.

Commands:
Chapter 2. Configuring the upgrade strategy for OpenShift AI As a cluster administrator, you can configure either an automatic or manual upgrade strategy for the Red Hat OpenShift AI Operator. Important By default, the Red Hat OpenShift AI Operator follows a sequential update process. This means that if there are several versions between the current version and the version that you intend to upgrade to, Operator Lifecycle Manager (OLM) upgrades the Operator to each of the intermediate versions before it upgrades it to the final, target version. If you configure automatic upgrades, OLM automatically upgrades the Operator to the latest available version, without human intervention. If you configure manual upgrades, a cluster administrator must manually approve each sequential update between the current version and the final, target version. For information about supported versions, see the Red Hat OpenShift AI Self-Managed Life Cycle Knowledgebase article. Prerequisites You have cluster administrator privileges for your OpenShift cluster. The Red Hat OpenShift AI Operator is installed. If you previously used the oc-mirror plugin v1 to mirror images, you have migrated to the oc-mirror plugin v2, as v1 is now deprecated. For more information, see Migrating from oc-mirror plugin v1 to v2 in the OpenShift documentation. You have mirrored the required container images to a private registry. See Mirroring images to a private registry for a disconnected installation . Procedure Log in to the OpenShift cluster web console as a cluster administrator. In the Administrator perspective, in the left menu, select Operators Installed Operators . Click the Red Hat OpenShift AI Operator. Click the Subscription tab. Under Update approval , click the pencil icon and select one of the following update strategies: Automatic : New updates are installed as soon as they become available. Manual : A cluster administrator must approve any new update before installation begins. Click Save . Additional resources For more information about the subscription channels that are available in version 2 of the Red Hat OpenShift AI Operator, see Installing the Red Hat OpenShift AI Operator . For more information about upgrading Operators that have been installed by using OLM, see Updating installed Operators in the OpenShift documentation.

Commands: