mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction Important Using the Red Hat Ceph file system (CephFS) through the native CephFS protocol is available only as a Technology Preview , and therefore is not fully supported by Red Hat. The deployment scenario described in this document should only be used for testing and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details . Note Red Hat supports using CephFS through NFS. For more information, see Deploying the Shared File Systems service with CephFS through NFS . With the OpenStack Shared File Systems service (manila) you can provision shared file systems that can be consumed by multiple compute instances. This release includes a technology preview of the necessary driver for Red Hat CephFS (namely, manila.share.drivers.cephfs.cephfs_native.CephFSNativeDriver ). This driver allows the Shared File System service to use CephFS as a back end. The recommended method for configuring a Shared File System back end is through the director. Doing so involves writing a custom environment file. With this release, the director can now deploy the Shared File System with a CephFS back end on the overcloud. This document explains how to do so.

Commands:
Chapter 9. Disabling Windows container workloads You can disable the capability to run Windows container workloads by uninstalling the Windows Machine Config Operator (WMCO) and deleting the namespace that was added by default when you installed the WMCO. 9.1. Uninstalling the Windows Machine Config Operator You can uninstall the Windows Machine Config Operator (WMCO) from your cluster. Prerequisites Delete the Windows Machine objects hosting your Windows workloads. Procedure From the Operators OperatorHub page, use the Filter by keyword box to search for Red Hat Windows Machine Config Operator . Click the Red Hat Windows Machine Config Operator tile. The Operator tile indicates it is installed. In the Windows Machine Config Operator descriptor page, click Uninstall . 9.2. Deleting the Windows Machine Config Operator namespace You can delete the namespace that was generated for the Windows Machine Config Operator (WMCO) by default. Prerequisites The WMCO is removed from your cluster. Procedure Remove all Windows workloads that were created in the openshift-windows-machine-config-operator namespace: USD oc delete --all pods --namespace=openshift-windows-machine-config-operator Verify that all pods in the openshift-windows-machine-config-operator namespace are deleted or are reporting a terminating state: USD oc get pods --namespace openshift-windows-machine-config-operator Delete the openshift-windows-machine-config-operator namespace: USD oc delete namespace openshift-windows-machine-config-operator Additional resources Deleting Operators from a cluster Removing Windows nodes .

Commands:
oc delete --all pods --namespace=openshift-windows-machine-config-operator
oc get pods --namespace openshift-windows-machine-config-operator
oc delete namespace openshift-windows-machine-config-operator
14.5.13. Displaying the Block Devices Associated with a Domain The domblklist domain --inactive --details displays a table of all block devices that are associated with the specified domain. If --inactive is specified, the result will show the devices that are to be used at the boot and will not show those that are currently running in use by the running domain. If --details is specified, the disk type and device value will be included in the table. The information displayed in this table can be used with the domblkinfo and snapshot-create .

Commands:
domblklist rhel6 --details
Chapter 2. Installing Apicurio Registry on OpenShift This chapter explains how to install Apicurio Registry on OpenShift Container Platform: Section 2.1, "Installing Apicurio Registry from the OpenShift OperatorHub" Prerequisites Read the introduction in the Red Hat build of Apicurio Registry User Guide . 2.1. Installing Apicurio Registry from the OpenShift OperatorHub You can install the Apicurio Registry Operator on your OpenShift cluster from the OperatorHub. The OperatorHub is available from the OpenShift Container Platform web console and provides an interface for cluster administrators to discover and install Operators. For more details, see Understanding OperatorHub . Note You can install more than one instance of Apicurio Registry depending on your environment. The number of instances depends on the number and type of artifacts stored in Apicurio Registry and on your chosen storage option. Prerequisites You must have cluster administrator access to an OpenShift cluster. Procedure In the OpenShift Container Platform web console, log in using an account with cluster administrator privileges. Create a new OpenShift project: In the left navigation menu, click Home , Project , and then Create Project . Enter a project name, for example, my-project , and click Create . In the left navigation menu, click Operators and then OperatorHub . In the Filter by keyword text box, enter registry to find the Red Hat Integration - Service Registry Operator . Read the information about the Operator, and click Install to display the Operator subscription page. Select your subscription settings, for example: Update Channel : Select one of the following: 2.x : Includes all minor and patch updates, such as 2.3.0 and 2.0.3. For example, an installation on 2.0.x will upgrade to 2.3.x. 2.0.x : Includes patch updates only, such as 2.0.1 and 2.0.2. For example, an installation on 2.0.x will ignore 2.3.x. Installation Mode : Select one of the following: All namespaces on the cluster (default) A specific namespace on the cluster and then my-project Approval Strategy : Select Automatic or Manual Click Install , and wait a few moments until the Operator is ready for use. Additional resources Adding Operators to an OpenShift cluster Apicurio Registry Operator community in GitHub

Commands:
8.6. Suspending an XFS File System To suspend or resume write activity to a file system, use xfs_freeze . Suspending write activity allows hardware-based device snapshots to be used to capture the file system in a consistent state. Note The xfs_freeze utility is provided by the xfsprogs package, which is only available on x86_64. To suspend (that is, freeze) an XFS file system, use: To unfreeze an XFS file system, use: When taking an LVM snapshot, it is not necessary to use xfs_freeze to suspend the file system first. Rather, the LVM management tools will automatically suspend the XFS file system before taking the snapshot. Note The xfs_freeze utility can also be used to freeze or unfreeze an ext3, ext4, GFS2, XFS, and BTRFS, file system. The syntax for doing so is the same. For more information about freezing and unfreezing an XFS file system, refer to man xfs_freeze .

Commands:
xfs_freeze -f /mount/point
xfs_freeze -u /mount/point
Chapter 249. Openshift Build Config Component Available as of Camel version 2.17 The OpenShift Build Config component is one of Kubernetes Components which provides a producer to execute kubernetes build config operations. 249.1. Component Options The Openshift Build Config component has no options. 249.2. Endpoint Options The Openshift Build Config endpoint is configured using URI syntax: with the following path and query parameters: 249.2.1. Path Parameters (1 parameters): Name Description Default Type masterUrl Required Kubernetes API server URL String 249.2.2. Query Parameters (20 parameters): Name Description Default Type apiVersion (producer) The Kubernetes API Version to use String dnsDomain (producer) The dns domain, used for ServiceCall EIP String kubernetesClient (producer) Default KubernetesClient to use if provided KubernetesClient operation (producer) Producer operation to do on Kubernetes String portName (producer) The port name, used for ServiceCall EIP String portProtocol (producer) The port protocol, used for ServiceCall EIP tcp String connectionTimeout (advanced) Connection timeout in milliseconds to use when making requests to the Kubernetes API server. Integer synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean caCertData (security) The CA Cert Data String caCertFile (security) The CA Cert File String clientCertData (security) The Client Cert Data String clientCertFile (security) The Client Cert File String clientKeyAlgo (security) The Key Algorithm used by the client String clientKeyData (security) The Client Key data String clientKeyFile (security) The Client Key file String clientKeyPassphrase (security) The Client Key Passphrase String oauthToken (security) The Auth Token String password (security) Password to connect to Kubernetes String trustCerts (security) Define if the certs we used are trusted anyway or not Boolean username (security) Username to connect to Kubernetes String

Commands:
openshift-build-configs:masterUrl
Chapter 6. dwz dwz is a command line tool that attempts to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size. To do so, dwz replaces DWARF information representation with equivalent smaller representation where possible and reduces the amount of duplication by using techniques from Appendix E of the DWARF Standard . Red Hat Developer Toolset is distributed with dwz 0.14 . 6.1. Installing dwz In Red Hat Developer Toolset, the dwz utility is provided by the devtoolset-12-dwz package and is automatically installed with devtoolset-12-toolchain as described in Section 1.5, "Installing Red Hat Developer Toolset" . 6.2. Using dwz To optimize DWARF debugging information in a binary file, run the dwz tool as follows: Note that you can execute any command using the scl utility, causing it to be run with the Red Hat Developer Toolset binaries used in preference to the Red Hat Enterprise Linux system equivalent. This allows you to run a shell session with Red Hat Developer Toolset dwz as default: Note To verify the version of dwz you are using at any point: Red Hat Developer Toolset's dwz executable path will begin with /opt . Alternatively, you can use the following command to confirm that the version number matches that for Red Hat Developer Toolset dwz : 6.3. Additional Resources For more information about dwz and its features, see the resources listed below. Installed Documentation dwz (1) - The manual page for the dwz utility provides detailed information on its usage. To display the manual page for the version included in Red Hat Developer Toolset: See Also Chapter 1, Red Hat Developer Toolset - An overview of Red Hat Developer Toolset and more information on how to install it on your system. Chapter 2, GNU Compiler Collection (GCC) - Instructions on compiling programs written in C, C++, and Fortran. Chapter 4, binutils - Instructions on using binutils , a collection of binary tools to inspect and manipulate object files and binaries. Chapter 5, elfutils - Instructions on using elfutils , a collection of binary tools to inspect and manipulate ELF files.

Commands:
scl enable devtoolset-12 'dwz option ... file_name '
scl enable devtoolset-12 'bash'
which dwz
dwz -v
scl enable devtoolset-12 'man dwz'
3.4. Basic Networking Terms Red Hat Virtualization provides networking functionality between virtual machines, virtualization hosts, and wider networks using: Logical networks A network interface controller (NIC) A Linux bridge A Bond A virtual network interface controller (vNIC) A virtual LAN (VLAN) NICs, Linux bridges, and vNICs enable network communication between hosts, virtual machines, local area networks, and the Internet. Bonds and VLANs are optionally implemented to enhance security, fault tolerance, and network capacity.

Commands:
3.6. Virtual Networking A virtual guest's connection to any network uses the software network components of the physical host. These software components can be rearranged and reconfigured by using libvirt 's virtual network configuration. The host therefore acts as a virtual network switch , which can be configured in a number of different ways to fit the guest's networking needs. By default, all guests on a single host are connected to the same libvirt virtual network, named default . Guests on this network can make the following connections: With each other and with the virtualization host Both inbound and outbound traffic is possible, but is affected by the firewalls in the guest operating system's network stack and by libvirt network filtering rules attached to the guest interface. With other hosts on the network beyond the virtualization host Only outbound traffic is possible, and is affected by Network Address Translation (NAT) rules, as well as the host system's firewall. However, if needed, guest interfaces can instead be set to one of the following modes: Isolated mode The guests are connected to a network that does not allow any traffic beyond the virtualization host. Routed mode The guests are connected to a network that routes traffic between the guest and external hosts without performing any NAT. This enables incoming connections but requires extra routing-table entries for systems on the external network. Bridged mode The guests are connected to a bridge device that is also connected directly to a physical ethernet device connected to the local ethernet. This makes the guest directly visible on the physical network, and thus enables incoming connections, but does not require any extra routing-table entries. For basic outbound-only network access from virtual machines, no additional network setup is usually needed, as the default network is installed along with the libvirt package, and automatically started when the libvirtd service is started. If more advanced functionality is needed, additional networks can be created and configured using either virsh or virt-manager , and the guest XML configuration file can be edited to use one of these new networks. Note For information on advanced virtual network settings, see the Red Hat Enterprise Linux 6 Virtualization Administration Guide . From the point of view of the guest operating system, a virtual network connection is the same as a normal physical network connection. For further information on configuring networks in Red Hat Enterprise Linux 6 guests, see the Red Hat Enterprise Linux 6 Deployment Guide .

Commands:
Chapter 3. Top Performance Considerations You can improve the performance and scalability of Red Hat Satellite: Configure httpd Configure Puma to increase concurrency Configure Candlepin Configure Pulp Configure Foreman's performance and scalability Configure Dynflow Deploy external Capsules instead of relying on internal Capsules Configure katello-agent for scalability Configure Hammer to reduce API timeouts Configure qpid and qdrouterd Improve PostgreSQL to handle more concurrent loads Configure the storage for DB workloads Ensure the storage requirements for Content Views are met Ensure the system requirements are met Improve the environment for remote execution

Commands:
Chapter 41. Capturing network packets To debug network issues and communications, you can capture network packets. The following sections provide instructions and additional information about capturing network packets. 41.1. Using xdpdump to capture network packets including packets dropped by XDP programs The xdpdump utility captures network packets. Unlike the tcpdump utility, xdpdump uses an extended Berkeley Packet Filter(eBPF) program for this task. This enables xdpdump to also capture packets dropped by Express Data Path (XDP) programs. User-space utilities, such as tcpdump , are not able to capture these dropped packages, as well as original packets modified by an XDP program. You can use xdpdump to debug XDP programs that are already attached to an interface. Therefore, the utility can capture packets before an XDP program is started and after it has finished. In the latter case, xdpdump also captures the XDP action. By default, xdpdump captures incoming packets at the entry of the XDP program. Important On other architectures than AMD and Intel 64-bit, the xdpdump utility is provided as a Technology Preview only. Technology Preview features are not supported with Red Hat production Service Level Agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These previews provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features. Note that xdpdump has no packet filter or decode capabilities. However, you can use it in combination with tcpdump for packet decoding. Prerequisites A network driver that supports XDP programs. An XDP program is loaded to the enp1s0 interface. If no program is loaded, xdpdump captures packets in a similar way tcpdump does, for backward compatibility. Procedure To capture packets on the enp1s0 interface and write them to the /root/capture.pcap file, enter: To stop capturing packets, press Ctrl + C . Additional resources xdpdump(8) man page on your system If you are a developer and you are interested in the source code of xdpdump , download and install the corresponding source RPM (SRPM) from the Red Hat Customer Portal. 41.2. Additional resources How to capture network packets with tcpdump? (Red Hat Knowledgebase)

Commands:
xdpdump -i enp1s0 -w /root/capture.pcap
1.8. Plan Ahead System administrators that took all this advice to heart and did their best to follow it would be fantastic system administrators -- for a day. Eventually, the environment will change, and one day our fantastic administrator would be caught flat-footed. The reason? Our fantastic administrator failed to plan ahead. Certainly no one can predict the future with 100% accuracy. However, with a bit of awareness it is easy to read the signs of many changes: An offhand mention of a new project gearing up during that boring weekly staff meeting is a sure sign that you will likely need to support new users in the near future Talk of an impending acquisition means that you may end up being responsible for new (and possibly incompatible) systems in one or more remote locations Being able to read these signs (and to respond effectively to them) makes life easier for you and your users.

Commands:
4.216. pam_ldap 4.216.1. RHBA-2011:1701 - pam_ldap bug fix update An updated pam_ldap package that fixes various bugs is now available for Red Hat Enterprise Linux 6. The pam_ldap package provides the pam_ldap.so module, which allows PAM-aware applications to check user passwords with the help of a directory server. Bug Fixes BZ# 735375 All entries stored in an LDAP directory have a unique "Distinguished Name," or DN. The top level of the LDAP directory tree is the base, referred to as the "base DN". When the host option is not set the pam_ldap.so module uses DNS SRV records to determine which servers to contact to perform authentication. Prior to this update, the LDAP base "DN" option was derived from the DNS domain name, ignoring any value that had been set for "base" in the pam_ldap.conf file. As a consequence, ldap lookups failed. The "base" setting in the configuration file, pam_ldap.conf, is now correctly parsed before the configuration is read from DNS. As a result, "base" is now set to the value given in the pam_ldap.conf file and is used as the base (starting point) to search for a user's credentials. BZ# 688747 Prior to this update, pam_ldap (when called by a process which was running as root) did not re-authenticate the user during a password change operation. As a consequence, reuse of the old password was not prevented. This update backports a fix to ensure that when a privileged application initiates a password change operation, for a user whose password has expired, that the current password is again verified, allowing client-side password-quality checking to be performed when using LDAP accounts. All users of pam_ldap are advised to upgrade to this updated package, which fixes these bugs.

Commands:
B.3.2. Verifying Signature of Packages To check the GnuPG signature of an RPM file after importing the builder's GnuPG key, use the following command (replace <rpm-file> with the file name of the RPM package): If all goes well, the following message is displayed: md5 gpg OK . This means that the signature of the package has been verified, that it is not corrupt, and therefore is safe to install and use.

Commands:
-K <rpm-file>
Chapter 9. Overview of NVMe over fabric devices Non-volatile Memory ExpressTM (NVMeTM) is an interface that allows host software utility to communicate with solid state drives. Use the following types of fabric transport to configure NVMe over fabric devices: NVMe over Remote Direct Memory Access (NVMe/RDMA) For information about how to configure NVMeTM/RDMA, see Configuring NVMe over fabrics using NVMe/RDMA . NVMe over Fibre Channel (NVMe/FC) For information about how to configure NVMeTM/FC, see Configuring NVMe over fabrics using NVMe/FC . NVMe over TCP (NVMe/TCP) For information about how to configure NVMe/FC, see Configuring NVMe over fabrics using NVMe/TCP . When using NVMe over fabrics, the solid-state drive does not have to be local to your system; it can be configured remotely through a NVMe over fabrics devices.

Commands:
Part VI. Custom tasks and work item handlers As a business rules developer, you can create custom tasks and work item handlers to execute custom code within your process flows and extend the operations available for use in Red Hat Process Automation Manager. You can use custom tasks to develop operations that Red Hat Process Automation Manager does not directly provide and include them in process diagrams. Custom tasks and work item handlers support Business Central, standalone editors, and Visual Studio Code (VS Code). This chapter describes how to use Business Central to create, manage, and deploy custom tasks and work item handlers. In Business Central, each task in a process diagram has a WorkItemDefinition Java class with an associated WorkItemHandler Java class. You can define a WorkItemDefinition using an MVFLEX Expression Language (MVEL) map as part of a MVEL list in a .wid file. Place the .wid file in the global directory under the project root or in the directory of the BPMN file. The work item handler contains Java code registered with Business Central and implements org.kie.api.runtime.process.WorkItemHandler . The Java code of the work item handler is executed when the task is triggered. You can customize and register a work item handler to execute your own Java code in custom tasks. Prerequisites Business Central is deployed and is running on a web or application server. You are logged in to Business Central. Maven is installed. The host has access to the Internet. The build process uses the Internet for downloading Maven packages from external repositories. Your system has access to the Red Hat Maven repository either locally or online

Commands:
19.2.3. Mail User Agent A Mail User Agent ( MUA ) is synonymous with an email client application. An MUA is a program that, at a minimum, allows a user to read and compose email messages. Many MUAs are capable of retrieving messages via the POP or IMAP protocols, setting up mailboxes to store messages, and sending outbound messages to an MTA. MUAs may be graphical, such as Evolution , or have simple text-based interfaces, such as pine .

Commands:
Chapter 4. steps This document shows how to configure and deploy a proof-of-concept version of Red Hat Quay. For more information on deploying to a production environment, see the guide "Deploy Red Hat Quay - High Availability". The "Use Red Hat Quay" guide shows you how to: Add users and repositories Use tags Automatically build Dockerfiles with build workers Set up build triggers Add notifications for repository events The "Manage Red Hat Quay" guide shows you how to: Use SSL and TLS Enable security scanning with Clair Use repository mirroring Configure LDAP authentication Use georeplication of storage

Commands: