mtpti5iD/redhat-docs_dataset huggingface dataset:
Deploying OpenShift Data Foundation using IBM Z Red Hat OpenShift Data Foundation 4.16 Instructions on deploying Red Hat OpenShift Data Foundation to use local storage on IBM Z Red Hat Storage Documentation Team Abstract Read this document for instructions about how to install Red Hat OpenShift Data Foundation to use local storage on IBM Z. Note While this document refers only to IBM Z, all information in it also applies to IBM(R) LinuxONE.

Commands:
19.3.4. Setting up emergency passphrases In some circumstances (such as traveling for business) it is impractical for system administrators to work directly with the affected systems, but users still need access to their data. In this case, volume_key can work with passphrases as well as encryption keys. During the system installation, run: This generates a random passphrase, adds it to the specified volume, and stores it to passphrase-packet . It is also possible to combine the --create-random-passphrase and -o options to generate both packets at the same time. If a user forgets the password, the designated user runs: This shows the random passphrase. Give this passphrase to the end user.

Commands:
volume_key --save /path/to/volume -c /path/to/ert --create-random-passphrase passphrase-packet
volume_key --secrets -d /your/nss/directory passphrase-packet
8.4. Monitoring snapshot health with the image discrepancies tool The RHV Image Discrepancies tool analyzes image data in the Storage Domain and RHV Database. It alerts you if it finds discrepancies in volumes and volume attributes, but does not fix those discrepancies. Use this tool in a variety of scenarios, such as: Before upgrading versions, to avoid carrying over broken volumes or chains to the new version. Following a failed storage operation, to detect volumes or attributes in a bad state. After restoring the RHV database or storage from backup. Periodically, to detect potential problems before they worsen. To analyze a snapshot- or live storage migration-related issues, and to verify system health after fixing these types of problems. Prerequisites Required Versions: this tool was introduced in RHV version 4.3.8 with rhv-log-collector-analyzer-0.2.15-0.el7ev . Because data collection runs simultaneously at different places and is not atomic, stop all activity in the environment that can modify the storage domains. That is, do not create or remove snapshots, edit, move, create, or remove disks. Otherwise, false detection of inconsistencies may occur. Virtual Machines can remain running normally during the process. Procedure To run the tool, enter the following command on the RHV Manager: If the tool finds discrepancies, rerun it to confirm the results, especially if there is a chance some operations were performed while the tool was running. Note This tool includes any Export and ISO storage domains and may report discrepancies for them. If so, these can be ignored, as these storage domains do not have entries for images in the RHV database. Understanding the results The tool reports the following: If there are volumes that appear on the storage but are not in the database, or appear in the database but are not on the storage. If some volume attributes differ between the storage and the database. Sample output:

Commands:
rhv-image-discrepancies
Checking storage domain c277ad93-0973-43d9-a0ca-22199bc8e801 Looking for missing images No missing images found Checking discrepancies between SD/DB attributes image ef325650-4b39-43cf-9e00-62b9f7659020 has a different attribute capacity on storage(2696984576) and on DB(2696986624) image 852613ce-79ee-4adc-a56a-ea650dcb4cfa has a different attribute capacity on storage(5424252928) and on DB(5424254976) Checking storage domain c64637b4-f0e8-408c-b8af-6a52946113e2 Looking for missing images No missing images found Checking discrepancies between SD/DB attributes No discrepancies found
4.7.3. Synchronizing Network Packet Filtering Rules If you are using iptables , you will need to synchronize the appropriate configuration file on the backup LVS router. If you alter the any network packet filter rules, enter the following command as root from the primary LVS router: scp /etc/sysconfig/iptables n.n.n.n :/etc/sysconfig/ In the command, replace n.n.n.n with the real IP address of the backup LVS router. either open an ssh session to the backup router or log into the machine as root and type the following command: /sbin/service iptables restart Once you have copied these files over to the backup router and started the appropriate services (see Section 2.1, "Configuring Services on the LVS Routers" for more on this topic) you are ready to start LVS.

Commands:
Chapter 17. Using 2-way replication with CephFS To reduce storage overhead with CephFS when data resiliency is not a primary concern, you can opt for using 2-way replication (replica-2). This reduces the amount of storage space used and decreases the level of fault tolerance. There are two ways to use replica-2 for CephFS: Edit the existing default pool to replica-2 and use it with the default CephFS storageclass . Add an additional CephFS data pool with replica-2 . 17.1. Editing the existing default CephFS data pool to replica-2 Use this procedure to edit the existing default CephFS pool to replica-2 and use it with the default CephFS storageclass. Procedure Patch the storagecluster to change default CephFS data pool to replica-2. Check the pool details. 17.2. Adding an additional CephFS data pool with replica-2 Use this procedure to add an additional CephFS data pool with replica-2. Prerequisites Ensure that you are logged into the OpenShift Container Platform web console and OpenShift Data Foundation cluster is in Ready state. Procedure Click Storage StorageClasses Create Storage Class . Select CephFS Provisioner . Under Storage Pool , click Create new storage pool . Fill in the Create Storage Pool fields. Under Data protection policy , select 2-way Replication . Confirm Storage Pool creation In the Storage Class creation form, choose the newly created Storage Pool. Confirm the Storage Class creation. Verification Click Storage Data Foundation . In the Storage systems tab, select the new storage system. The Details tab of the storage system reflect the correct volume and device types you chose during creation

Commands:
oc patch storagecluster ocs-storagecluster -n openshift-storage --type json --patch '[{ "op": "replace", "path": "/spec/managedResources/cephFilesystems/dataPoolSpec/replicated/size", "value": 2 }]' storagecluster.ocs.openshift.io/ocs-storagecluster patched
oc get cephfilesystem ocs-storagecluster-cephfilesystem -o=jsonpath='{.spec.dataPools}' | jq [ { "application": "", "deviceClass": "ssd", "erasureCoded": { "codingChunks": 0, "dataChunks": 0 }, "failureDomain": "zone", "mirroring": {}, "quotas": {}, "replicated": { "replicasPerFailureDomain": 1, "size": 2, "targetSizeRatio": 0.49 }, "statusCheck": { "mirror": {} } } ]
ceph osd pool ls | grep filesystem ocs-storagecluster-cephfilesystem-metadata ocs-storagecluster-cephfilesystem-data0
Appendix B. Additional Resources To learn more about virtualization and Red Hat Enterprise Linux, refer to the following resources. B.1. Online Resources http://www.libvirt.org/ is the official website for the libvirt virtualization API. https://virt-manager.org/ is the project website for the Virtual Machine Manager (virt-manager), the graphical application for managing virtual machines. Red Hat Virtualization - http://www.redhat.com/products/cloud-computing/virtualization/ Red Hat product documentation - https://access.redhat.com/documentation/en/ Virtualization technologies overview - http://virt.kernelnewbies.org

Commands:
Chapter 1. Overview of Red Hat Developer Hub Red Hat Developer Hub (Developer Hub) serves as an open developer platform designed for building developer portals and is based on the backstage project. Using Developer Hub, the engineering teams can access a unified platform that streamlines the development process and provides a variety of tools and resources to build high-quality software efficiently. The goal of Developer Hub is to address the difficulties associated with creating and sustaining developer portals using: A centralized dashboard to view all available developer tools and resources to increase productivity Self-service capabilities, along with guardrails, for cloud-native application development that complies with enterprise-class best practices Proper security and governance for all developers across the enterprise The Red Hat Developer Hub simplifies decision-making by providing a developer experience that presents a selection of internally approved tools, programming languages, and various developer resources within a self-managed portal. This approach contributes to the acceleration of application development and the maintenance of code quality, all while fostering innovation.

Commands:
4.5. Tuning the Database Cache for Searches The database attributes that affect search performance mainly define the amount of memory available to the server. The maximum values that can be set for the database's cache size attributes depends on the amount of real memory on the machine. Roughly, the amount of available memory on the machine should always be greater than sum total of the default database cache size and sum of each entry cache size. Use caution when changing these cache sizing attributes. The ability to improve server performance with these attributes depends on the size of the database, the amount of physical memory available on the machine, and whether directory searches are random (that is, if the directory clients are searching for random and widely scattered directory data). If the database does not fit into memory and if searches are random, attempting to increase the values set on these attributes does not help directory performance. In fact, changing these attributes may harm overall performance. The attributes of each database used to store directory data can be resized. To improve the cache hit ratio on search operations, increase the amount of data that the Directory Server maintains in the database cache, as described in Section 6.5, "Setting the Database Cache Size" , by editing the values for the nsslapd-dbcachesize parameter.

Commands:
3.4. Associative Arrays SystemTap also supports the use of associative arrays. While an ordinary variable represents a single value, associative arrays can represent a collection of values. Simply put, an associative array is a collection of unique keys; each key in the array has a value associated with it. Since associative arrays are normally processed in multiple probes (as we will demonstrate later), they should be declared as global variables in the SystemTap script. The syntax for accessing an element in an associative array is similar to that of awk , and is as follows: Here, the array_name is any arbitrary name the array uses. The index_expression is used to refer to a specific unique key in the array. To illustrate, let us try to build an array named foo that specifies the ages of three people (that is the unique keys): tom , dick , and harry . To assign them the ages (that is associated values) of 23, 24, and 25 respectively, we can use the following array statements: Example 3.11. Basic Array Statements You can specify up to nine index expressions in an array statement, each one delimited by a comma ( , ). This is useful if you wish to have a key that contains multiple pieces of information. The following line from disktop.stp uses 5 elements for the key: process ID, executable name, user ID, parent process ID, and string "W". It associates the value of devname with that key. Important All associate arrays must be declared as global , regardless of whether the associate array is used in one or multiple probes.

Commands:
array_name [ index_expression ]
foo["tom"] = 23 foo["dick"] = 24 foo["harry"] = 25
device[pid(),execname(),uid(),ppid(),"W"] = devname
Chapter 6. Updating Directory Server to a new minor version Red Hat frequently releases updated versions of Red Hat Directory Server 12. This section describes how to update the Directory Server packages. In case you want to migrate Red Hat Directory Server from version 10 or 11 to version 12, see: Migrating Directory Server 10 to Directory Server 12 Migrating Directory Server 11 to Directory Server 12 6.1. Updating the Directory Server packages Use the dnf utility to update the module, which also automatically updates the related packages. Prerequisites You have installed Directory Server packages. You have a valid Red Hat Directory Server subscription in your Red Hat account. Procedure Disable all versioned Directory Server repositories: Enable the new Directory Server repository: Note that starting from Directory Server 12.5, you need to perform this step only once because the repository name no longer changes. Important Extended Update Support (EUS) version has a separate dirsrv-12-for-rhel-9-x86_64- eus -rpms repository. Additionally, Directory Server EUS version requires you to have enabled RHEL EUS repositories. For more information about Directory Server repositories, see What are the names of the Red Hat repositories that have to be enabled? Red Hat Knowledgebase article. Update the Directory Server packages and their dependencies to the latest available version: The update process automatically restarts the dirsrv services for all instances on the server. Additional resources Enabling Directory Server repositories

Commands:
subscription-manager repos --disable dirsrv-12.*-for-rhel-9-x86_64-rpms
subscription-manager repos --enable=dirsrv-12-for-rhel-9-x86_64-rpms Repository 'dirsrv-12-for-rhel-9-x86_64-rpms' is enabled for this system.
dnf update 389-ds-base cockpit-389-ds
B.5. bzip2 B.5.1. RHSA-2010:0858 - Important: bzip2 security update Updated bzip2 packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link(s) associated with each description below. bzip2 is a freely available, high-quality data compressor. It provides both standalone compression and decompression utilities, as well as a shared library for use with other programs. CVE-2010-0405 An integer overflow flaw was discovered in the bzip2 decompression routine. This issue could, when decompressing malformed archives, cause bzip2, or an application linked against the libbz2 library, to crash or, potentially, execute arbitrary code. Users of bzip2 should upgrade to these updated packages, which contain a backported patch to resolve this issue. All running applications using the libbz2 library must be restarted for the update to take effect.

Commands:
8.200. rhn-client-tools 8.200.1. RHBA-2014:1537 - rhn-client-tools bug fix update Updated rhn-client-tools packages that fix two bugs are now available for Red Hat Enterprise Linux 6. Red Hat Network Client Tools provide programs and libraries that allow a system to receive software updates from Red Hat Network. Bug Fixes BZ# 873784 Previously, when specifying multiple server URL values in the /etc/sysconfig/rhn/up2date config file and the string did not end with a semicolon character, the last server URL value could not be used by Yum. With this update, Yum can use all valid URL values even if the string does not end with a semicolon. BZ# 1019184 Several translation errors for the ko_KR, pt_BR, ru_RU, and zh_CN locales have been corrected. Users of rhn-client-tools are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 11. Scaling Multicloud Object Gateway performance by adding endpoints The Multicloud Object Gateway (MCG) performance may vary from one environment to another. In some cases, specific applications require faster performance which can be easily addressed by scaling S3 endpoints. The MCG resource pool is a group of NooBaa daemon containers that provide two types of services enabled by default: Storage service S3 endpoint service S3 endpoint service The S3 endpoint is a service that every Multicloud Object Gateway (MCG) provides by default that handles the heavy lifting data digestion in the MCG. The endpoint service handles the inline data chunking, deduplication, compression, and encryption, and it accepts data placement instructions from the MCG. 11.1. Automatic scaling of MultiCloud Object Gateway endpoints The number of MultiCloud Object Gateway (MCG) endpoints scale automatically when the load on the MCG S3 service increases or decreases. OpenShift Data Foundation clusters are deployed with one active MCG endpoint. Each MCG endpoint pod is configured by default with 1 CPU and 2Gi memory request, with limits matching the request. When the CPU load on the endpoint crosses over an 80% usage threshold for a consistent period of time, a second endpoint is deployed lowering the load on the first endpoint. When the average CPU load on both endpoints falls below the 80% threshold for a consistent period of time, one of the endpoints is deleted. This feature improves performance and serviceability of the MCG. 11.2. Scaling the Multicloud Object Gateway with storage nodes Prerequisites A running OpenShift Data Foundation cluster on OpenShift Container Platform with access to the Multicloud Object Gateway (MCG). A storage node in the MCG is a NooBaa daemon container attached to one or more Persistent Volumes (PVs) and used for local object service data storage. NooBaa daemons can be deployed on Kubernetes nodes. This can be done by creating a Kubernetes pool consisting of StatefulSet pods. Procedure Log in to OpenShift Web Console . From the MCG user interface, click Overview Add Storage Resources . In the window, click Deploy Kubernetes Pool . In the Create Pool step create the target pool for the future installed nodes. In the Configure step, configure the number of requested pods and the size of each PV. For each new pod, one PV is to be created. In the Review step, you can find the details of the new pool and select the deployment method you wish to use: local or external deployment. If local deployment is selected, the Kubernetes nodes will deploy within the cluster. If external deployment is selected, you will be provided with a YAML file to run externally. All nodes will be assigned to the pool you chose in the first step, and can be found under Resources Storage resources Resource name .

Commands:
1.7. Red Hat JBoss Data Grid APIs Red Hat JBoss Data Grid provides the following programmable APIs: Cache Batching Grouping Persistence (formerly CacheStore) ConfigurationBuilder Externalizable Notification (also known as the Listener API because it deals with Notifications and Listeners) JBoss Data Grid offers the following APIs to interact with the data grid in Remote Client-Server mode: The Asynchronous API (can only be used in conjunction with the Hot Rod Client in Remote Client-Server Mode) The REST Interface The Memcached Interface The Hot Rod Interface The RemoteCache API Report a bug

Commands:
Chapter 1. Getting Started with Spring Boot standalone 1.1. About Spring Boot standalone deployment mode In standalone deployment mode, a Spring Boot application is packaged as a Jar file and run directly inside the Java Virtual Machine (JVM). This approach to packaging and running the application is consistent with the microservices philosophy, where a service is packaged with the minimum set of requirements. The Spring Boot application can be run directly using the java command with the -jar option. For example: Where Spring Boot provides the main class for the executable Jar. The following elements are required for building a Spring Boot standalone application in Fuse: The Fuse Bill of Materials (BOM) - defines a carefully curated set of dependencies from the Red Hat Maven repository. The BOM exploits Maven's dependency management mechanism to define the appropriate versions of Maven dependencies. Note: Only the dependencies defined in the Fuse BOM are supported by Red Hat. The Spring Boot Maven Plugin - implements the build process for a standalone Spring Boot application in Maven. This plugin is responsible for packaging your Spring Boot application as an executable Jar file. 1.2. Deploying into Spring Boot 2 In standalone deployment mode, you have the option of deploying into Spring Boot 2. Note For details about the OpenShift mode of deployment, see the Fuse on OpenShift Guide . 1.3. New Camel Components for Spring Boot 2 Spring Boot 2 supports Camel version 2.23 and supports some new camel components that are listed below: New Camel Components for Spring Boot 2 as2-component aws-iam-component fhir-component google-calendar-stream-component google-mail-stream-component google-sheets-component google-sheets-stream-component ipfs-component kubernetes-hpa-component kubernetes-job-component micrometer-component mybatis-bean-component nsq-component rxjava2 service-component spring-cloud-consul spring-cloud-zookeeper testcontainers-spring testcontainers web3j-component

Commands:
java -jar SpringBootApplication.jar
8.4. Resolving Common Queuing/Frame Loss Issues By far, the most common reason for frame loss is a queue overrun . The kernel sets a limit to the length of a queue, and in some cases the queue fills faster than it drains. When this occurs for too long, frames start to get dropped. As illustrated in Figure 8.1, "Network receive path diagram" , there are two major queues in the receive path: the NIC hardware buffer and the socket queue. Both queues need to be configured accordingly to protect against queue overruns. 8.4.1. NIC Hardware Buffer The NIC fills its hardware buffer with frames; the buffer is then drained by the softirq , which the NIC asserts via an interrupt. To interrogate the status of this queue, use the following command: Replace ethX with the NIC's corresponding device name. This will display how many frames have been dropped within ethX . Often, a drop occurs because the queue runs out of buffer space in which to store frames. There are different ways to address this problem, namely: Input traffic You can help prevent queue overruns by slowing down input traffic. This can be achieved by filtering, reducing the number of joined multicast groups, lowering broadcast traffic, and the like. Queue length Alternatively, you can also increase the queue length. This involves increasing the number of buffers in a specified queue to whatever maximum the driver will allow. To do so, edit the rx / tx ring parameters of ethX using: Append the appropriate rx or tx values to the aforementioned command. For more information, refer to man ethtool . Device weight You can also increase the rate at which a queue is drained. To do this, adjust the NIC's device weight accordingly. This attribute refers to the maximum number of frames that the NIC can receive before the softirq context has to yield the CPU and reschedule itself. It is controlled by the /proc/sys/net/core/dev_weight variable. Most administrators have a tendency to choose the third option. However, keep in mind that there are consequences for doing so. Increasing the number of frames that can be received from a NIC in one iteration implies extra CPU cycles, during which no applications can be scheduled on that CPU.

Commands:
ethtool -S ethX
ethtool --set-ring ethX
18.12.11.3. Command line tools virsh has been extended with life-cycle support for network filters. All commands related to the network filtering subsystem start with the prefix nwfilter . The following commands are available: nwfilter-list : lists UUIDs and names of all network filters nwfilter-define : defines a new network filter or updates an existing one (must supply a name) nwfilter-undefine : deletes a specified network filter (must supply a name). Do not delete a network filter currently in use. nwfilter-dumpxml : displays a specified network filter (must supply a name) nwfilter-edit : edits a specified network filter (must supply a name)

Commands: