mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Installation methods You can install OpenShift Container Platform on IBM Cloud(R) using installer-provisioned infrastructure. This process involves using an installation program to provision the underlying infrastructure for your cluster. Installing OpenShift Container Platform on IBM Cloud(R) using user-provisioned infrastructure is not supported at this time. See Installation process for more information about installer-provisioned installation processes. 1.1. Installing a cluster on installer-provisioned infrastructure You can install a cluster on IBM Cloud(R) infrastructure that is provisioned by the OpenShift Container Platform installation program by using one of the following methods: Installing a customized cluster on IBM Cloud(R) : You can install a customized cluster on IBM Cloud(R) infrastructure that the installation program provisions. The installation program allows for some customization to be applied at the installation stage. Many other customization options are available post-installation . Installing a cluster on IBM Cloud(R) with network customizations : You can customize your OpenShift Container Platform network configuration during installation, so that your cluster can coexist with your existing IP address allocations and adhere to your network requirements. Installing a cluster on IBM Cloud(R) into an existing VPC : You can install OpenShift Container Platform on an existing IBM Cloud(R). You can use this installation method if you have constraints set by the guidelines of your company, such as limits when creating new accounts or infrastructure. Installing a private cluster on an existing VPC : You can install a private cluster on an existing Virtual Private Cloud (VPC). You can use this method to deploy OpenShift Container Platform on an internal network that is not visible to the internet. Installing a cluster on IBM Cloud in a restricted network : You can install OpenShift Container Platform on IBM Cloud on installer-provisioned infrastructure by using an internal mirror of the installation release content. You can use this method to install a cluster that does not require an active internet connection to obtain the software components. 1.2. steps Configuring an IBM Cloud(R) account

Commands:
Chapter 2. Introduction to content creator workflows and automation execution environments 2.1. About content workflows Before Red Hat Ansible Automation Platform 2.0, an automation content developer may have needed so many Python virtual environments that they required their own automation in order to manage them. To reduce this level of complexity, Ansible Automation Platform 2.0 is moving away from virtual environments and using containers, referred to as automation execution environments, instead, as they are straightforward to build and manage and are more shareable across teams and orgs. As automation controller shifts to using automation execution environments, tools like Automation content navigator and Ansible Builder ensure that you can take advantage of those automation execution environments locally within your own development system. Additional resources See the Automation Content Navigator Creator Guide for more on using Automation content navigator. For more information on Ansible Builder, see Creating and Consuming Execution Environments . 2.2. Architecture overview The following list shows the arrangements and uses of tools available on Ansible Automation Platform 2.0, along with how they can be utilized: Automation content navigator only - can be used today in Ansible Automation Platform 1.2 Automation content navigator + downloaded automation execution environments - used directly on laptop/workstation Automation content navigator + downloaded automation execution environments + automation controller - for pushing/executing locally remotely Automation content navigator + automation controller + Ansible Builder + Layered custom EE - provides even more control over utilized content for how to execute automation jobs

Commands:
3.13. Searching for Disks The following table describes all search options for disks. Note You can use the Disk Type and Content Type filtering options to reduce the number of displayed virtual disks. Table 3.9. Searching for Disks Property (of resource or resource-type) Type Description (Reference) Datacenters. datacenters-prop Depends on property type The property of the data centers associated with the disk. Storages. storages-prop Depends on property type The property of the storage associated with the disk. alias String The human readable name that identifies the storage on the network. description String Keywords or text describing the disk, optionally used when creating the disk. provisioned_size Integer The virtual size of the disk. size Integer The size of the disk. actual_size Integer The actual size allocated to the disk. creation_date Integer The date the disk was created. bootable String Whether the disk can or cannot be booted. Valid values are one of 0 , 1 , yes , or no shareable String Whether the disk can or cannot be attached to more than one virtual machine at a time. Valid values are one of 0 , 1 , yes , or no format String The format of the disk. Can be one of unused , unassigned , cow , or raw . status String The status of the disk. Can be one of unassigned , ok , locked , invalid , or illegal . disk_type String The type of the disk. Can be one of image or lun . number_of_vms Integer The number of virtual machine(s) to which the disk is attached. vm_names String The name(s) of the virtual machine(s) to which the disk is attached. quota String The name of the quota enforced on the virtual disk. sortby List Sorts the returned results by one of the resource properties. page Integer The page number of results to display. Example Disks: format = cow and provisioned_size > 8 This example returns a list of virtual disks with QCOW format and an allocated disk size greater than 8 GB.

Commands:
Preface Depending on the type of your deployment, you can choose one of the following procedures to replace a storage device: For dynamically created storage clusters deployed on AWS, see: Section 1.1, "Replacing operational or failed storage devices on AWS user-provisioned infrastructure" . Section 1.2, "Replacing operational or failed storage devices on AWS installer-provisioned infrastructure" . For dynamically created storage clusters deployed on VMware, see Section 2.1, "Replacing operational or failed storage devices on VMware infrastructure" . For dynamically created storage clusters deployed on Red Hat Virtualization, see Section 3.1, "Replacing operational or failed storage devices on Red Hat Virtualization installer-provisioned infrastructure" . For dynamically created storage clusters deployed on Microsoft Azure, see Section 4.1, "Replacing operational or failed storage devices on Azure installer-provisioned infrastructure" . For storage clusters deployed using local storage devices, see: Section 5.1, "Replacing operational or failed storage devices on clusters backed by local storage devices" . Section 5.2, "Replacing operational or failed storage devices on IBM Power" . Section 5.3, "Replacing operational or failed storage devices on IBM Z or LinuxONE infrastructure" . Note OpenShift Data Foundation does not support heterogeneous OSD sizes.

Commands:
3.2. Initial Setup Tasks Initial GFS setup consists of the following tasks: Setting up logical volumes. Making a GFS files system. Mounting file systems. Follow these steps to set up GFS initially. Using CLVM (Cluster Logical Volume Manager), create a logical volume for each Red Hat GFS file system. Note You can use init.d scripts included with Red Hat Cluster Suite to automate activating and deactivating logical volumes. For more information about init.d scripts, refer to Configuring and Managing a Red Hat Cluster . Create GFS file systems on logical volumes created in Step 1. Choose a unique name for each file system. For more information about creating a GFS file system, refer to Section 4.1, "Making a File System" . Command usage: gfs_mkfs -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice At each node, mount the GFS file systems. For more information about mounting a GFS file system, refer to Section 4.2, "Mounting a File System" . Command usage: mount -t gfs BlockDevice MountPoint mount -t gfs -o acl BlockDevice MountPoint The -o acl mount option allows manipulating file ACLs. If a file system is mounted without the -o acl mount option, users are allowed to view ACLs (with getfacl ), but are not allowed to set them (with setfacl ). Note You can use init.d scripts included with Red Hat Cluster Suite to automate mounting and unmounting GFS file systems. For more information about init.d scripts, refer to Configuring and Managing a Red Hat Cluster .

Commands:
5.2. Model Extension Definition (MED) The purpose of a MED is to define one or more sets of extension properties. Each set of extension properties pertains to one model object type (or metaclass). Each MED consists of the following: Namespace Prefix - a unique identifier. Typically only a small number of letters and can be used as an abbreviation for the namespace URI. Namespace URI - a unique URI. Extended Metamodel URI (Model Class) - the metamodel URI that is being extended. Each metamodel URI also has model class and that is typically what is shown in the Designer. The model classes supported for extension are: Relational, Web Service, XML Document, and Function. Version - (currently not being used) Description - an optional description or purpose. Extended Model Object Types (Metaclasses) - a set of model object types, or metaclasses, that have extension properties defined. Properties - the extension property definitions grouped by model object type. A MED file is an XML file with an extension of mxd . A MED schema file is used to validate a MED file. Here is a sample MED file: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <modelExtension xmlns:p="http://org.teiid.modelExtension/2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" metamodelUri="http://www.metamatrix.com/metamodels/Relational" namespacePrefix="mymodelextension" namespaceUri="org.my.extension.mymodelextension" version="1" xsi:schemaLocation="http://org.teiid.modelExtension/2011 modelExtension.xsd" xmlns="http://org.teiid.modelExtension/2011"> <p:description>This is my model extension</p:description> <p:extendedMetaclass name="com.metamatrix.metamodels.relational.impl.BaseTableImpl"> <p:property advanced="false" index="true" masked="false" name="copyable" required="false" type="boolean"> <p:description locale="en_US">Indicates if table can be copied</p:description> <p:display locale="en_US">Copyable</p:display> </p:property> </p:extendedMetaclass> </modelExtension> The MED Registry is where the MEDs used by Teiid Designer are stored. MED files can be edited by opening the .mxd file in the Extension Editor.

Commands:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <modelExtension xmlns:p="http://org.teiid.modelExtension/2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" metamodelUri="http://www.metamatrix.com/metamodels/Relational" namespacePrefix="mymodelextension" namespaceUri="org.my.extension.mymodelextension" version="1" xsi:schemaLocation="http://org.teiid.modelExtension/2011 modelExtension.xsd" xmlns="http://org.teiid.modelExtension/2011"> <p:description>This is my model extension</p:description> <p:extendedMetaclass name="com.metamatrix.metamodels.relational.impl.BaseTableImpl"> <p:property advanced="false" index="true" masked="false" name="copyable" required="false" type="boolean"> <p:description locale="en_US">Indicates if table can be copied</p:description> <p:display locale="en_US">Copyable</p:display> </p:property> </p:extendedMetaclass> </modelExtension>
Chapter 56. EntityOperatorTemplate schema reference Used in: EntityOperatorSpec Property Property type Description deployment DeploymentTemplate Template for Entity Operator Deployment . pod PodTemplate Template for Entity Operator Pods . topicOperatorContainer ContainerTemplate Template for the Entity Topic Operator container. userOperatorContainer ContainerTemplate Template for the Entity User Operator container. tlsSidecarContainer ContainerTemplate The tlsSidecarContainer property has been deprecated. TLS sidecar was removed in Streams for Apache Kafka 2.8. This property is ignored. Template for the Entity Operator TLS sidecar container. serviceAccount ResourceTemplate Template for the Entity Operator service account. entityOperatorRole ResourceTemplate Template for the Entity Operator Role. topicOperatorRoleBinding ResourceTemplate Template for the Entity Topic Operator RoleBinding. userOperatorRoleBinding ResourceTemplate Template for the Entity Topic Operator RoleBinding.

Commands:
Chapter 1. Automation of JBoss EAP deployments by using an Ansible collection Ansible is an information technology (IT) automation engine that you can use to automate and simplify cloud provisioning, configuration management, application deployment, intraservice orchestration, and other tasks across your IT enterprise. An Ansible collection is a standardized distribution format for reusable Ansible content such as playbooks, roles, modules, and plug-ins. Red Hat provides a series of prepackaged Red Hat Ansible Certified Content Collections. You can use these certified content collections to enable the automated deployment of various Red Hat Runtimes products such as Red Hat JBoss Enterprise Application Platform (JBoss EAP) in your system. 1.1. Ansible concepts and benefits Ansible includes various elements such as playbooks, roles, content collections, and automation execution environments. Using Ansible to automate IT processes, workflows, and infrastructure lifecycles provides multiple benefits to your enterprise. If you are unfamiliar with Ansible architecture or you want more information about the benefits of using Ansible, refer to the following Additional resources links. Additional resources How Ansible works Understanding Ansible concepts Learning Ansible basics Red Hat Ansible Automation Platform product page 1.2. JBoss EAP collection For general information about the JBoss EAP collection, refer to the JBoss EAP Collection for Ansible - redhat.eap page in Ansible automation hub . The JBoss EAP Collection for Ansible - redhat.eap page includes information about the roles that the collection contains. You can click the name of a role to view details about the purpose of this role, any requirements or dependencies, and the list of variables and default settings that the role uses to complete automation tasks. Additional resources Ansible Content Collections

Commands:
7.2.3. Line Printers Another type of impact printer somewhat similar to the daisy-wheel is the line printer . However, instead of a print wheel, line printers have a mechanism that allows multiple characters to be simultaneously printed on the same line. The mechanism may use a large spinning print drum or a looped print chain . As the drum or chain is rotated over the paper's surface, electromechanical hammers behind the paper push the paper (along with a ribbon) onto the surface of the drum or chain, marking the paper with the shape of the character on the drum or chain. Because of the nature of the print mechanism, line printers are much faster than dot-matrix or daisy-wheel printers. However, they tend to be quite loud, have limited multi-font capability, and often produce lower print quality than more recent printing technologies. Because line printers are used for their speed, they use special tractor-fed paper with pre-punched holes along each side. This arrangement makes continuous unattended high-speed printing possible, with stops only required when a box of paper runs out.

Commands:
B.2. How to Set Up Red Hat Virtualization Manager to Use Ethtool You can configure ethtool properties for host network interface cards from the Administration Portal. The ethtool_opts key is not available by default and needs to be added to the Manager using the engine configuration tool. You also need to install the required VDSM hook package on the hosts. Adding the ethtool_opts Key to the Manager On the Manager, run the following command to add the key: Restart the ovirt-engine service: On the hosts that you want to configure ethtool properties, install the VDSM hook package. The package is available by default on Red Hat Virtualization Host but needs to be installed on Red Hat Enterprise Linux hosts. The ethtool_opts key is now available in the Administration Portal. See Section 9.4.2, "Editing Host Network Interfaces and Assigning Logical Networks to Hosts" to apply ethtool properties to logical networks.

Commands:
engine-config -s UserDefinedNetworkCustomProperties=ethtool_opts=.* --cver=4.0
systemctl restart ovirt-engine.service
yum install vdsm-hook-ethtool-options
7.4. Using Docker on Red Hat Enterprise Linux 7 Docker and Docker Registry have been released as part of the Extras channel in Red Hat Enterprise Linux. Once the Extras channel has been enabled, the packages can be installed in the usual way. For more information on installing packages or enabling channels, see System Administrator's Guide . Red Hat provides a registry of certified docker formatted container images. This registry provides pre-built solutions usable on Red Hat Enterprise Linux 7 with the Docker service. To download container images from the Red Hat Atomic Registry, see the Red Hat Atomic Container Images search page . Downloading images is done using the docker pull command. Note that you will need to have the docker service running to be able to use this command.

Commands:
12.6. NFS-based Storage Pools This procedure covers creating a storage pool with a NFS mount point in virt-manager . 12.6.1. Creating an NFS-based Storage Pool with virt-manager Open the host physical machine's storage tab Open the Storage tab in the Host Details window. Open virt-manager . Select a host physical machine from the main virt-manager window. Click Edit menu and select Connection Details . Figure 12.24. Connection details Click on the Storage tab. Figure 12.25. Storage tab Create a new pool (part 1) Press the + button (the add pool button). The Add a New Storage Pool wizard appears. Figure 12.26. Add an NFS name and type Choose a name for the storage pool and press Forward to continue. Create a new pool (part 2) Enter the target path for the device, the host name and the NFS share path. Set the Format option to NFS or auto (to detect the type). The target path must be identical on all host physical machines for migration. Enter the host name or IP address of the NFS server. This example uses server1.example.com . Enter the NFS path. This example uses /nfstrial . Figure 12.27. Create an NFS storage pool Press Finish to create the new storage pool.

Commands:
Chapter 6. Securing the Fuse Console See the Managing Fuse on Karaf Standalone guide for information on how to implement the following security features to secure Fuse containers for standalone deployments: Set HTTPS as the required protocol Use public keys to secure responses Enable SSL/TLS security Control user access By default, the Fuse Console is not accessible remotely. For information on how to access the Fuse Console remotely, see the unlocking the Fuse Console section in the Managing Fuse on Karaf Standalone guide.

Commands:
17.5. Using Cross-Pair Certificates In the late 1990s, as the US government began enhancing its public key infrastructure, it became apparent that branches of government with their own, separate PKI deployments still needed to be able to recognize and trust each others certificates as if the certificates were issued from their own CA. (The method of getting certificates trusted outside a network for external clients to use is a serious, not easily resolved issue for any PKI administrator.) The US government devised a standard for issuing cross-pair certificates called the Federal Bridge Certificate Authority. These certificates are also called bridge certificates , for obvious reasons. Bridge or cross-pair certificates are CA signing certificate that are framed as dual certificate pairs, similar to encryption and signing certificate pairs for users, only each certificate in the pair is issued by a different CA. Both partner CAs store the other CA signing certificate in its database, so all of the certificates issued within the other PKI are trusted and recognized. Bridging certificates honors certificates issued by a CA that is not chained to the root CA in its own PKI. By establishing a trust between the Certificate System CA and another CA through a cross-pair CA certificate, the cross-pair certificate can be downloaded and used to trust the certificates issued by the other CA, just as downloading and installing a single CA certificate trusts all certificates issued by the CA. The Certificate System can issue, import, and publish cross-pair CA certificates. A special profile must be created for issuing cross-pair certificates, and then the certificates can be requested and installed for the CA using the Certificate Wizard for the CA subsystem. For more information on creating cross-pair certificate profiles, see the Configuring Cross-Pair profiles section in the Red Hat Certificate System Planning, Installation, and Deployment Guide . For more information on publishing cross-pair certificates, see Section 9.9, "Publishing Cross-Pair Certificates" . 17.5.1. Installing Cross-Pair Certificates Both cross-pair certificates can be imported into the Certificate System databases using the certutil tool or by selecting the Cross-Pair Certificates option from the Certificate Setup Wizard, as described in Section 17.6.1, "Installing Certificates in the Certificate System Database" . When both certificates have been imported into the database, a crossCertificatePair entry is formed and stored in the database. The original individual cross-pair CA certificates are deleted once the crossCertificatePair entry is created. 17.5.2. Searching for Cross-Pair Certificates Both CAs in bridge certificates can store or publish the cross-pair certificates as a crossCertificatePair entry in an LDAP database. The Certificate Manager's internal database can be searched for the crossCertificatePair entry with ldapsearch .

Commands:
/usr/lib[64]/mozldap/ldapsearch -D "cn=directory manager" -w secret -p 389 -h server.example.com -b "o=server.example.com-pki-ca" -s sub "(crossCertificatePair=*)"
8.58. grep 8.58.1. RHBA-2013:0977 - grep bug fix update Updated grep packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The grep utility searches through textual input for lines which contain a match to a specified pattern and then prints the matching lines. GNU grep utilities include grep, egrep and fgrep. Bug Fixes BZ# 715295 For some regular expressions, the DFA analysis could insert up to double "positions" than there were leaves. Consequently, there were not enough room to insert all the positions and grep could terminate unexpectedly on certain regular expressions. To fix this problem, space allocation has been increased and grep works as expected in the described scenario. BZ#797934 When a fixed string pattern was empty while the case-insensitive search was active, grep could terminate unexpectedly. With this update, the check for this case has been added to the code and grep works as expected in the described scenario. BZ# 826997 Previously, the code handling case-insensitive searches could alter a string's byte size while converting it to lower case. Consequently, grep could truncate certain output strings. To fix this bug, the grep code has been modified to correctly handle such cases when the byte size gets altered during the conversion to lower case. As a result, case-insensitive searches work correctly and grep no longer truncates its output. Users of grep are advised to upgrade to these updated packages, which fix these bugs.

Commands: