mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Checking for Local Storage Operator deployments Red Hat OpenShift Data Foundation clusters with Local Storage Operator are deployed using local storage devices. To find out if your existing cluster with OpenShift Data Foundation was deployed using local storage devices, use the following procedure: Prerequisites OpenShift Data Foundation is installed and running in the openshift-storage namespace. Procedure By checking the storage class associated with your OpenShift Data Foundation cluster's persistent volume claims (PVCs), you can tell if your cluster was deployed using local storage devices. Check the storage class associated with OpenShift Data Foundation cluster's PVCs with the following command: Check the output. For clusters with Local Storage Operators, the PVCs associated with ocs-deviceset use the storage class localblock . The output looks similar to the following: Additional Resources Deploying OpenShift Data Foundation using local storage devices on VMware Deploying OpenShift Data Foundation using local storage devices on Red Hat Virtualization Deploying OpenShift Data Foundation using local storage devices on bare metal Deploying OpenShift Data Foundation using local storage devices on IBM Power

Commands:
oc get pvc -n openshift-storage
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-d96c747b-2ab5-47e2-b07e-1079623748d8 50Gi RWO ocs-storagecluster-ceph-rbd 114s ocs-deviceset-0-0-lzfrd Bound local-pv-7e70c77c 1769Gi RWO localblock 2m10s ocs-deviceset-1-0-7rggl Bound local-pv-b19b3d48 1769Gi RWO localblock 2m10s ocs-deviceset-2-0-znhk8 Bound local-pv-e9f22cdc 1769Gi RWO localblock 2m10s
Chapter 8. Quota management architecture With the quota management feature enabled, individual blob sizes are summed at the repository and namespace level. For example, if two tags in the same repository reference the same blob, the size of that blob is only counted once towards the repository total. Additionally, manifest list totals are counted toward the repository total. Important Because manifest list totals are counted toward the repository total, the total quota consumed when upgrading from a version of Red Hat Quay might be reportedly differently in Red Hat Quay 3.9. In some cases, the new total might go over a repository's previously-set limit. Red Hat Quay administrators might have to adjust the allotted quota of a repository to account for these changes. The quota management feature works by calculating the size of existing repositories and namespace with a backfill worker, and then adding or subtracting from the total for every image that is pushed or garbage collected afterwords. Additionally, the subtraction from the total happens when the manifest is garbage collected. Note Because subtraction occurs from the total when the manifest is garbage collected, there is a delay in the size calculation until it is able to be garbage collected. For more information about garbage collection, see Red Hat Quay garbage collection . The following database tables hold the quota repository size, quota namespace size, and quota registry size, in bytes, of a Red Hat Quay repository within an organization: QuotaRepositorySize QuotaNameSpaceSize QuotaRegistrySize The organization size is calculated by the backfill worker to ensure that it is not duplicated. When an image push is initialized, the user's organization storage is validated to check if it is beyond the configured quota limits. If an image push exceeds defined quota limitations, a soft or hard check occurs: For a soft check, users are notified. For a hard check, the push is stopped. If storage consumption is within configured quota limits, the push is allowed to proceed. Image manifest deletion follows a similar flow, whereby the links between associated image tags and the manifest are deleted. Additionally, after the image manifest is deleted, the repository size is recalculated and updated in the QuotaRepositorySize , QuotaNameSpaceSize , and QuotaRegistrySize tables.

Commands:
Chapter 3. Bug fixes In this release of Red Hat Trusted Artifact Signer (RHTAS), we fixed the following bugs. In addition to these fixes, we list the descriptions of previously known issues found in earlier versions that we fixed. Added missing options to configure hostname With this release, you can now configure the hostname for the cli-server and the rekor-search-ui . You can configure the hostname by specifying the --cli-server-hostname= HOSTNAME on the RHTAS operator controller. You can also configure the hostname by using the API, for example: ... rekor: rekorSearchUI: host: HOSTNAME ... Replace HOSTNAME with your hostname. Segment backup job fails on OpenShift clusters that use self-signed certificates The segment backup job was failing when verifying a self-signed certificate causing Secure Socket Layer (SSL) certificate verification errors. Because this verification failed, the job could not pull metrics from the cluster monitoring system by using OpenShift's internal API. We fixed this bug by injecting OpenShift's Certificate Authority (CA) trusted bundle into the RHTAS containers. By doing this, the segment backup job can verify the self-signed certificate, and can successfully pull the necessary metrics. Version number reported incorrectly on OpenShift 4.13 Before this update, the installation of the RHTAS operator on OpenShift Container Platform 4.13 incorrectly shows version 0.0.2, when version 1.0 is actually installed. With this release, the RHTAS operator version number is correctly displayed on OpenShift Container Platform 4.13. Removed pull-secret references In early releases of RHTAS, you were asked to give a pull secret to install RHTAS. Since the General Availability (GA) release of RHTAS, you no longer need a pull secret to deploy RHTAS on Red Hat OpenShift. With this release, we removed all references to pull-secret from the RHTAS code base. Changes to the treeID field are not applied to the Rekor deployment When making a change to the treeID field in the Rekor configuration this change was not updated in the Rekor deployment. This bug could cause wrong log entries, and cause other potential issues with Rekor. We fixed the logic in the Rekor manager to prevent inconsistencies, and as a result improving the reliability of the Rekor service. With this release, updating the treeID field correctly updates the Rekor deployment as expected, and shows the correct status.treeID value. Changes to the treeID field are not applied to the CT log deployment When making a change to the treeID field in the Certificate Transparency (CT) log configuration this change was not updated in the CT log deployment. This bug could cause inconsistencies, and other potential issues with CT log. We fixed the logic in the CT log manager to prevent inconsistencies, and as a result improving the reliability of the CT log service. With this release, updating the treeID field correctly updates the CT log deployment as expected, and shows the correct status.treeID value.

Commands:
rekor: rekorSearchUI: host: HOSTNAME
15.2. Back Ends for GVFS There is a number of back ends in GVFS , which provide access to a specific type of resource. The following is a list of available GVFS back ends and their specifications: Table 15.1. Available Back Ends Back end Description afc Similar to MTP (Media Transfer Protocol), exposes files on your Apple iDevice (connected through USB). afp Apple Filing Protocol ( AFP ) client to access file services of Mac operation system X and original Mac operation system. archive Handles various archiving files (ZIP, TAR) in read-only way. burn A virtual back end used by burning applications as a temporary storage for new CD/DVD/BD medium contents. cdda Exposes Audio CD through separate Waveform Audio File Format ( WAV ) files. computer Virtual back end consolidating active mounts and physical volumes. Acts similarly to a signpost. Previously used by Nautilus for its Computer view. dav, davs WebDAV client, including secure variant. Authentication is possible only during mount, does not support later re-authentication on per-folder basis. dns-sd DNS Service Discovery - Avahi client, used during network browsing, forms persistent URIs to discovered services. ftp A fully featured FTP (File Transfer Protocol) client, without FTPS support for the time being. Supports passive transfers by default. gphoto2 A Picture Transfer Protocol ( PTP ) client to access your camera attached by USB or FireWire. http Handles all HTTP requests; useful for easy downloading files from web in client applications. locatest Simple testing back end proxying file:/// URI.; with error injection support. mtp Media Transfer Protocol back end for accessing media player and smart phones memory. network For browsing the network, showing nearby Avahi and Samba servers. obexftp A Bluetooth client. recent A back end used in GtkFileChooser to list recent files used by GNOME applications. sftp A fully-featured SFTP (SSH File Transfer Protocol) client. smb Access Samba and Windows shares. trash A trash back end which allows to restore deleted files. Note Some back ends are packaged separately and not installed by default. For installing additional back ends, use the yum package manager. To use services of a back end, an URI string must be formed. This string is a basic identifier used in GVFS , which carries all necessary information needed for unique identification, such as type of service (back end ID), absolute path and user name if needed. You can see this information in the Nautilus address bar and GTK+ open or save file dialogs. The example below is a very basic form of the URI string and points to a root directory (/) of the FTP (File Transfer Protocol) server running at ftp.myserver.net domain: Example 15.1. URI String Pointing to the Root Directory The following example points to a text file in a specified path using authentication: Example 15.2. URI String Pointing to a Text File

Commands:
ftp://ftp.myserver.net/
ssh://joe@ftp.myserver.net/home/joe/todo.txt
Chapter 6. Using the Ceph block device Python module The rbd python module provides file-like access to Ceph block device images. In order to use this built-in tool, import the rbd and rados Python modules. Prerequisites A running Red Hat Ceph Storage cluster. Root-level access to the node. Procedure Connect to RADOS and open an IO context: cluster = rados.Rados(conffile='my_ceph.conf') cluster.connect() ioctx = cluster.open_ioctx('mypool') Instantiate an :class:rbd.RBD object, which you use to create the image: To perform I/O on the image, instantiate an :class:rbd.Image object: This writes 'foo' to the first 600 bytes of the image. Note that data cannot be :type:unicode - librbd does not know how to deal with characters wider than a :c:type:char . Close the image, the IO context and the connection to RADOS: To be safe, each of these calls must to be in a separate :finally block: This can be cumbersome, so the Rados , Ioctx , and Image classes can be used as context managers that close or shut down automatically. Using them as context managers, the above example becomes:

Commands:
cluster = rados.Rados(conffile='my_ceph.conf') cluster.connect() ioctx = cluster.open_ioctx('mypool')
rbd_inst = rbd.RBD() size = 4 * 1024**3 # 4 GiB rbd_inst.create(ioctx, 'myimage', size)
image = rbd.Image(ioctx, 'myimage') data = 'foo' * 200 image.write(data, 0)
image.close() ioctx.close() cluster.shutdown()
import rados import rbd cluster = rados.Rados(conffile='my_ceph_conf') try: ioctx = cluster.open_ioctx('my_pool') try: rbd_inst = rbd.RBD() size = 4 * 1024**3 # 4 GiB rbd_inst.create(ioctx, 'myimage', size) image = rbd.Image(ioctx, 'myimage') try: data = 'foo' * 200 image.write(data, 0) finally: image.close() finally: ioctx.close() finally: cluster.shutdown()
with rados.Rados(conffile='my_ceph.conf') as cluster: with cluster.open_ioctx('mypool') as ioctx: rbd_inst = rbd.RBD() size = 4 * 1024**3 # 4 GiB rbd_inst.create(ioctx, 'myimage', size) with rbd.Image(ioctx, 'myimage') as image: data = 'foo' * 200 image.write(data, 0)
Appendix A. Revision History Note that revision numbers relate to the edition of this manual, not to version numbers of Red Hat Directory Server. Revision History Revision 11.5-1 Tue May 10 2022 Marc Muehlfeld Red Hat Directory Server 11.5 release of this guide. Revision 11.4-1 Tue Nov 09 2021 Marc Muehlfeld Red Hat Directory Server 11.4 release of this guide. Revision 11.3-1 Tue May 11 2021 Marc Muehlfeld Red Hat Directory Server 11.3 release of this guide. Revision 11.2-1 Tue Nov 03 2020 Marc Muehlfeld Red Hat Directory Server 11.2 release of this guide. Revision 11.1-1 Tue Apr 28 2020 Marc Muehlfeld Red Hat Directory Server 11.1 release of this guide. Revision History Revision 11.0-1 Tue Nov 05 2019 Marc Muehlfeld Red Hat Directory Server 11.0 release of this guide.

Commands:
Chapter 10. Performance and Scalability Performance Co-Pilot (PCP) Performance Co-Pilot (PCP) provides a framework and services to support system-level performance monitoring and management. Its light-weight, distributed architecture makes it particularly well-suited to centralized analysis of complex systems. Performance metrics can be added using the Python, Perl, C++ and C interfaces. Analysis tools can use the client APIs (Python, C++, C) directly, and rich web applications can explore all available performance data using a JSON interface. For further information, consult the extensive man pages in the pcp and pcp-libs-devel packages. The pcp-doc package installs documentation in the /usr/share/doc/pcp-doc/* directory, which also includes these two free and open books from the upstream project: http://www.performancecopilot.org/doc/pcp-users-and-administrators-guide.pdf http://www.performancecopilot.org/doc//pcp-programmers-guide.pdf

Commands:
Chapter 1. Configuring accounts for RHEL AI There are a few accounts you need to set up before interacting with RHEL AI. Creating a Red Hat account You can create a Red Hat account by registering on the Red Hat website. You can follow the procedure in Register for a Red Hat account . Creating a Red Hat registry account Before you can download models from the Red Hat registry, you need to create a registry account and login using the CLI. You can view your account username and password by selecting the Regenerate Token button on the webpage. You can create a Red Hat registry account by selecting the New Service Account button on the Registry Service Accounts page. There are several ways you can log into your registry account via the CLI. Follow the procedure in Red Hat Container Registry authentication to login on your machine. Optional: Configuring Red Hat Insights for hybrid cloud deployments Red Hat Insights is an offering that gives you visibility to the environments you are deploying. This platform can also help identify operational and vulnerability risks in your system. For more information about Red Hat Insights, see Red Hat Insights data and application security . You can create a Red Hat Insights account using an activation key and organization parameters by following the procedure in Viewing an activation key . You can then configure your account on your machine by running the following command: USD rhc connect --organization <org id> --activation-key <created key> To run RHEL AI in a disconnected environment, or opt out of Red Hat Insights, run the following commands: USD sudo mkdir -p /etc/ilab USD sudo touch /etc/ilab/insights-opt-out

Commands:
rhc connect --organization <org id> --activation-key <created key>
sudo mkdir -p /etc/ilab sudo touch /etc/ilab/insights-opt-out
Appendix C. Using AMQ Broker with the examples The AMQ JMS Pool examples require a running message broker with a queue named queue . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named queue . USD <broker-instance-dir> /bin/artemis queue create --name queue --address queue --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-05-07 10:16:34 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name queue --address queue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
Chapter 6. The Infinispan Query DSL The Infinispan Query DSL provides an unified way of querying a cache. It can be used in Library mode for both indexed and indexless queries, as well as for Remote Querying (via the Hot Rod Java client). The Infinispan Query DSL allows queries without relying on Lucene native query API or Hibernate Search query API. Indexless queries are only available with the Infinispan Query DSL for both the JBoss Data Grid remote and embedded mode. Indexless queries do not require a configured index (see Section 6.2, "Enabling Infinispan Query DSL-based Queries" ). The Hibernate Search/Lucene-based API cannot use indexless queries. 23151%2C+Infinispan+Query+Guide-6.608-09-2016+09%3A23%3A32JBoss+Data+Grid+6Documentation6.6.1 Report a bug 6.1. Creating Queries with Infinispan Query DSL The new query API is located in the org.infinispan.query.dsl package. A query is created with the assistance of the QueryFactory instance, which is obtained using Search.getQueryFactory() . Each QueryFactory instance is bound to the one cache instance, and is a stateless and thread-safe object that can be used for creating multiple parallel queries. The Infinispan Query DSL uses the following steps to perform a query. A query is created by invocating the from(Class entityType) method, which returns a QueryBuilder object that is responsible for creating queries for the specified entity class from the given cache. The QueryBuilder accumulates search criteria and configuration specified through invoking its DSL methods, and is used to build a Query object by invoking the QueryBuilder.build() method, which completes the construction. The QueryBuilder object cannot be used for constructing multiple queries at the same time except for nested queries, however it can be reused afterwards. Invoke the list() method of the Query object to execute the query and fetch the results. Once executed, the Query object is not reusable. If new results must be fetched, a new instance must be obtained by calling QueryBuilder.build() . Important A query targets a single entity type and is evaluated over the contents of a single cache. Running a query over multiple caches, or creating queries targeting several entity types is not supported. Report a bug

Commands:
12.3. Running Services The service utility allows you to start, stop, or restart the services from the /etc/init.d/ directory. 12.3.1. Determining the Service Status To determine the current status of a service, type the following at a shell prompt: service service_name status For example, to determine the status of the httpd service, type: To display the status of all available services at once, run the service command with the --status-all option: Note that you can also use the Service Configuration utility as described in Section 12.2.1, "Using the Service Configuration Utility" .

Commands:
~]# service httpd status httpd (pid 7474) is running
~]# service --status-all abrt (pid 1492) is running acpid (pid 1305) is running atd (pid 1540) is running auditd (pid 1103) is running automount (pid 1315) is running Avahi daemon is running cpuspeed is stopped ... several lines omitted wpa_supplicant (pid 1227) is running
Chapter 10. Cluster Quorum A Red Hat Enterprise Linux High Availability Add-On cluster uses the votequorum service, in conjunction with fencing, to avoid split brain situations. A number of votes is assigned to each system in the cluster, and cluster operations are allowed to proceed only when a majority of votes is present. The service must be loaded into all nodes or none; if it is loaded into a subset of cluster nodes, the results will be unpredictable. For information on the configuration and operation of the votequorum service, see the votequorum (5) man page. 10.1. Configuring Quorum Options There are some special features of quorum configuration that you can set when you create a cluster with the pcs cluster setup command. Table 10.1, "Quorum Options" summarizes these options. Table 10.1. Quorum Options Option Description --auto_tie_breaker When enabled, the cluster can suffer up to 50% of the nodes failing at the same time, in a deterministic fashion. The cluster partition, or the set of nodes that are still in contact with the nodeid configured in auto_tie_breaker_node (or lowest nodeid if not set), will remain quorate. The other nodes will be inquorate. The auto_tie_breaker option is principally used for clusters with an even number of nodes, as it allows the cluster to continue operation with an even split. For more complex failures, such as multiple, uneven splits, it is recommended that you use a quorum device, as described in Section 10.5, "Quorum Devices" . The auto_tie_breaker option is incompatible with quorum devices. --wait_for_all When enabled, the cluster will be quorate for the first time only after all nodes have been visible at least once at the same time. The wait_for_all option is primarily used for two-node clusters and for even-node clusters using the quorum device lms (last man standing) algorithm. The wait_for_all option is automatically enabled when a cluster has two nodes, does not use a quorum device, and auto_tie_breaker is disabled. You can override this by explicitly setting wait_for_all to 0. --last_man_standing When enabled, the cluster can dynamically recalculate expected_votes and quorum under specific circumstances. You must enable wait_for_all when you enable this option. The last_man_standing option is incompatible with quorum devices. --last_man_standing_window The time, in milliseconds, to wait before recalculating expected_votes and quorum after a cluster loses nodes. For further information about configuring and using these options, see the votequorum (5) man page.

Commands: