mtpti5iD/redhat-docs_dataset huggingface dataset:
B.3.5. Testing the Resource Configuration In the cluster status display shown in Section B.3.4, "Creating the Resources and Resource Groups with the pcs Command" , all of the resources are running on node z1.example.com . You can test whether the resource group fails over to node z2.example.com by using the following procedure to put the first node in standby mode, after which the node will no longer be able to host resources. The following command puts node z1.example.com in standby mode. After putting node z1 in standby mode, check the cluster status. Note that the resources should now all be running on z2 . The web site at the defined IP address should still display, without interruption. To remove z1 from standby mode, enter the following command. Note Removing a node from standby mode does not in itself cause the resources to fail back over to that node. For information on controlling which node resources can run on, see the chapter on configuring cluster resources in the Red Hat High Availability Add-On Reference .

Commands:
root@z1 ~]# pcs cluster standby z1.example.com
pcs status Cluster name: my_cluster Last updated: Wed Jul 31 17:16:17 2013 Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com Stack: corosync Current DC: z2.example.com (2) - partition with quorum Version: 1.1.10-5.el7-9abe687 2 Nodes configured 6 Resources configured Node z1.example.com (1): standby Online: [ z2.example.com ] Full list of resources: myapc (stonith:fence_apc_snmp): Started z1.example.com Resource Group: apachegroup my_lvm (ocf::heartbeat:LVM): Started z2.example.com my_fs (ocf::heartbeat:Filesystem): Started z2.example.com VirtualIP (ocf::heartbeat:IPaddr2): Started z2.example.com Website (ocf::heartbeat:apache): Started z2.example.com
root@z1 ~]# pcs cluster unstandby z1.example.com
Chapter 3. Networking 3.1. Host networking On the data link layer (layer 2), RHV enables the configuration of Linux bonds to connect to VLANs and define the MTU for network interfaces. These networks can be shared via Linux bridges to virtual machines. For SR-IOV, you can configure the number of virtual functions and their mapping to logical networks. FCoE manages its own VLANs. These FCoE managed VLANs are used exclusively for storage access. They are invisible to the Manager and any virtual machines. iSCSI manages iSCSI bonds. They are not part of RHV's visible host network configuration. You can use iSCSI without iSCSI bonds, which are useful only to improve the reliability of iSCSI storage. Important All hosts in a cluster must use either IPv4 or IPv6 as the IP stack for their management network. Dual stack is not supported. You can configure the DNS resolver that the host uses. It is also possible to manage network roles and QoS.

Commands:
1.3. Dependencies The Ruby Software Development Kit has the following dependencies, which you must install manually if you are using gem : libxml2 for parsing and rendering XML libcurl for HTTP transfers C compiler Required header and library files Note You do not need to install the dependency files if you installed the RPM. Install the dependency files: Note If you are using Fedora or CentOS, use dnf : If you are using Debian or Ubuntu, use apt-get :

Commands:
yum install gcc libcurl-devel libxml2-devel ruby-devel
dnf install gcc libcurl-devel libxml2-devel ruby-devel
apt-get install gcc libxml2-dev libcurl-dev ruby-dev
Chapter 20. Deploying the MortgageApprovalProcess process application The following chapter instructs you how to build and deploy a new instance of the Mortgage_Process application in Red Hat Process Automation Manager. Prerequisites KIE Server is deployed and connected to Business Central. Procedure In Business Central, go to Menu Design Projects Mortgage_Process . Click Deploy . If no KIE container (deployment unit) is included with the project name, a container with default values is automatically created. If an older version of the project is already deployed, go to the project settings and change the project version. When finished, save the change and click Deploy . This deploys a new version of the same project with the latest changes in place, alongside the older version(s). Note You can also select the Build & Install option to build the project and publish the KJAR file to the configured Maven repository without deploying to a KIE Server. In a development environment, you can click Deploy to deploy the built KJAR file to a KIE Server without stopping any running instances (if applicable), or click Redeploy to deploy the built KJAR file and replace all instances. The time you deploy or redeploy the built KJAR, the deployment unit (KIE container) is automatically updated in the same target KIE Server. In a production environment, the Redeploy option is disabled and you can click Deploy only to deploy the built KJAR file to a new deployment unit (KIE container) on a KIE Server. To configure the KIE Server environment mode, set the org.kie.server.mode system property to org.kie.server.mode=development or org.kie.server.mode=production . To configure the deployment behavior for a corresponding project in Business Central, go to project Settings General Settings Version and toggle the Development Mode option. By default, KIE Server and all new projects in Business Central are in development mode. You cannot deploy a project with Development Mode turned on or with a manually added SNAPSHOT version suffix to a KIE Server that is in production mode. To review project deployment details, click View deployment details in the deployment banner at the top of the screen or in the Deploy drop-down menu. This option directs you to the Menu Deploy Execution Servers page.

Commands:
Chapter 2. Performing the pre-customization tasks 2.1. Working with ISO images In this section, you will learn how to: Extract a Red Hat ISO. Create a new boot image containing your customizations. 2.2. Downloading RH boot images Before you begin to customize the installer, download the Red Hat-provided boot images. You can obtain Red Hat Enterprise Linux 8 boot media from the Red Hat Customer Portal after login to your account. Note Your account must have sufficient entitlements to download Red Hat Enterprise Linux 8 images. You must download either the Binary DVD or Boot ISO image and can use any of the image variants (Server or ComputeNode). You cannot customize the installer using the other available downloads, such as the KVM Guest Image or Supplementary DVD; other available downloads, such as the KVM Guest Image or Supplementary DVD . For more information about the Binary DVD and Boot ISO downloads, see Product Downloads . 2.3. Extracting Red Hat Enterprise Linux boot images Perform the following procedure to extract the contents of a boot image. Procedure Ensure that the directory /mnt/iso exists and nothing is currently mounted there. Mount the downloaded image. Where path/to/image.iso is the path to the downloaded boot image. Create a working directory where you want to place the contents of the ISO image. Copy all contents of the mounted image to your new working directory. Make sure to use the -p option to preserve file and directory permissions and ownership. Unmount the image. Additional resources For more information about the Binary DVD and Boot ISO downloads, see Product Downloads .

Commands:
mount -t iso9660 -o loop path/to/image.iso /mnt/iso
mkdir /tmp/ISO
cp -pRf /mnt/iso /tmp/ISO
umount /mnt/iso
C.4.5. Create File Systems on the Mapped Device or Continue to Build Complex Storage Structures Using the Mapped Device Use the mapped device node ( /dev/mapper/<name> ) as any other block device. To create an ext2 filesystem on the mapped device, use the following command: To mount this filesystem on /mnt/test , use the following command: Important The directory /mnt/test must exist before executing this command.

Commands:
mke2fs /dev/mapper/<name>
mount /dev/mapper/<name> /mnt/test
Chapter 10. Contacting developers This guide explains how to find out which developer account manages a particular application and then communicate with them - both through 3scale and externally. During API operations, you may urgently need to contact developers who are using your API. 10.1. Locate the relevant application and account in the system If you already know the account and developer who manages the application in question, navigate to their account from the Accounts page in Audience > Accounts > Listing , as shown below. If you only have the application ID or API key, you can use the search box on the Accounts page in Audience > Accounts > Listing to find the relevant account. More information on locating applications is available here . 10.2. Send internal messages to developers Once you are in the account profile page as shown below, click the message icon. The message created here will be sent both to the account system dashboard, where all developers on the account will see it, and by email to the people on the developer account who have admin status within the account. 10.3. Contact by other means If it's an emergency and email is unlikely to be fast enough for your purposes, you can also use the contact information submitted by the developer at time of signup, which is available: On the company account page (general contact information but may include a phone number). Developer/user specific information on the users' own file. Note that you can make contact phone numbers a required field upon signup.

Commands:
Chapter 6. Pass-Through certification A Pass-Through Certification refers to the ability of a third-party system or component to be granted certification for hardware previously certified by the original hardware manufacturer. Pass-Through can reduce the overall amount of testing that is required to be performed and submitted to Red Hat to achieve certification for the third-party hardware. System manufacturers can extend a certification granted to their own systems to another vendor's system where the original vendor: Has permission from the third-party, Has the mechanics to ensure the third-party does not alter the hardware in such a way that it would no longer be considered a subset of the original model certified by Red Hat, and Extends their responsibilities of support and representative hardware to include situations involving third-party hardware. The third-party cannot then extend their Pass-Through Certification to another vendor. While both vendors are required to be members of the Red Hat Hardware Certification Program, only the original vendor may request Pass-Through Certifications. Vendors may also utilize the Pass-Through process, where the same vendor has multiple names for the same hardware.

Commands:
Chapter 6. Ensuring that data displays correctly in the Fuse Console If the display of the queues and connections in the Fuse Console is missing queues, missing connections, or displaying inconsistent icons, adjust the Jolokia collection size parameter that specifies the maximum number of elements in an array that Jolokia marshals in a response. Procedure In the upper right corner of the Fuse Console, click the user icon and then click Preferences . Increase the value of the Maximum collection size option (the default is 50,000). Click Close .

Commands:
4.7. Configuring Virtual NUMA In the Administration Portal, you can configure virtual NUMA nodes on a virtual machine and pin them to physical NUMA nodes on one or more hosts. The host's default policy is to schedule and run virtual machines on any available resources on the host. As a result, the resources backing a large virtual machine that cannot fit within a single host socket could be spread out across multiple NUMA nodes. Over time these resources may be moved around, leading to poor and unpredictable performance. Configure and pin virtual NUMA nodes to avoid this outcome and improve performance. Configuring virtual NUMA requires a NUMA-enabled host. To confirm whether NUMA is enabled on a host, log in to the host and run numactl --hardware . The output of this command should show at least two NUMA nodes. You can also view the host's NUMA topology in the Administration Portal by selecting the host from the Hosts tab and clicking NUMA Support . This button is only available when the selected host has at least two NUMA nodes. Note If you define NUMA Pinning , the default migration mode is Allow manual migration only by default. Configuring Virtual NUMA Click Compute Virtual Machines and select a virtual machine. Click Edit . Click Show Advanced Options . Click the Host tab. Select the Specific Host(s) radio button and select the host(s) from the list. The selected host(s) must have at least two NUMA nodes. Click NUMA Pinning . In the NUMA Topology window, click and drag virtual NUMA nodes from the box on the right to host NUMA nodes on the left as required, and click OK . Select Strict , Preferred , or Interleave from the Tune Mode drop-down list in each NUMA node. If the selected mode is Preferred , the NUMA Node Count must be set to 1 . You can also set the NUMA pinning policy automatically by selecting Resize and Pin NUMA from the CPU Pinning Polcy drop-down list under the CPU Allocation settings in the Resource Allocation tab: None - Runs without any CPU pinning. Manual - Runs a manually specified virtual CPU on a specific physical CPU and a specific host. Available only when the virtual machine is pinned to a Host. Resize and Pin NUMA - Resizes the virtual CPU and NUMA topology of the virtual machine according to the Host, and pins them to the Host resources. Dedicated - Exclusively pins virtual CPUs to host physical CPUs. Available for cluster compatibility level 4.7 or later. If the virtual machine has NUMA enabled, all nodes must be unpinned. Isolate Threads - Exclusively pins virtual CPUs to host physical CPUs. Each virtual CPU gets a physical core. Available for cluster compatibility level 4.7 or later. If the virtual machine has NUMA enabled, all nodes must be unpinned. Click OK . Note If you do not pin the virtual NUMA node to a host NUMA node, the system defaults to the NUMA node that contains the host device's memory-mapped I/O (MMIO), provided that there are one or more host devices and all of those devices are from a single NUMA node.

Commands:
15.19. Forcing Replication Updates If you stop a Directory Server instance that is involved in replication for regular maintenance, you must update the replication immediately when it comes back online. In the case of a supplier in a multi-supplier environment, the directory information needs to be updated by an other supplier in the setup. In other cases, for example if you take down a hub or a dedicated consumer for maintenance and then come back online later, the supplier server needs to update the status. Prerequisites The replication is set up. The consumer has been initialized. Procedure Check if the replication agreement has an update schedule configured: If the output of the command contains nsDS5ReplicaUpdateSchedule: * or the nsDS5ReplicaUpdateSchedule parameter is not present, no update schedule is configured. If nsDS5ReplicaUpdateSchedule contains a schedule, such as shown below, note the value: If an update schedule is configured, enter the following command to temporary disable it: Temporarily disable the replication agreement: Re-enable the replication agreement to force the replication update: If a replication schedule was configured at the beginning of this procedure, set the schedule to the value:

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt get --suffix=" dc=example,dc=com " agreement_name
nsDS5ReplicaUpdateSchedule: 0800-2200 0246
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt set --schedule \* --suffix=" dc=example,dc=com " agreement_name
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt disable --suffix=" dc=example,dc=com " agreement_name
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt enable --suffix=" dc=example,dc=com " agreement_name
dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt set --schedule " 0800-2200 0246 " --suffix=" dc=example,dc=com " agreement_name
C.7.2. Useful Websites http://www.X.org/ - Home page of the X.Org Foundation, which produces major releases of the X Window System bundled with Red Hat Enterprise Linux to control the necessary hardware and provide a GUI environment. http://dri.sourceforge.net/ - Home page of the DRI (Direct Rendering Infrastructure) project. The DRI is the core hardware 3D acceleration component of X. http://www.gnome.org/ - Home of the GNOME project. http://www.kde.org/ - Home of the KDE desktop environment.

Commands:
Chapter 19. CIDR range definitions You must specify non-overlapping ranges for the following CIDR ranges. Note Machine CIDR ranges cannot be changed after creating your cluster. Important OVN-Kubernetes, the default network provider in OpenShift Container Platform 4.11 to 4.13, uses the following IP address ranges internally: 100.64.0.0/16 , 169.254.169.0/29 , fd98::/64 and fd69::/125 . If your cluster uses OVN-Kubernetes, do not include any IP address ranges in any other CIDR definitions in your cluster. 19.1. Machine CIDR In the Machine classless inter-domain routing (CIDR) field, you must specify the IP address range for machines or cluster nodes. The default is 10.0.0.0/16 . This range must not conflict with any connected networks. 19.2. Service CIDR In the Service CIDR field, you must specify the IP address range for services. The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 172.30.0.0/16 . 19.3. Pod CIDR In the pod CIDR field, you must specify the IP address range for pods. The pod CIDR is the same as the clusterNetwork CIDR and the cluster CIDR. The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 10.128.0.0/14 . You can expand the range after cluster installation. Additional resources Cluster Network Operator Configuration 19.4. Host Prefix In the Host Prefix field, you must specify the subnet prefix length assigned to pods scheduled to individual machines. The host prefix determines the pod IP address pool for each machine. For example, if the host prefix is set to /23 , each machine is assigned a /23 subnet from the pod CIDR address range. The default is /23 , allowing 510 cluster nodes, and 510 pod IP addresses per node.

Commands:
7.2. Cache Entry Modified Listener Configuration In a cache entry modified listener event, The getValue() method's behavior is specific to whether the callback is triggered before or after the actual operation has been performed. For example, if event.isPre() is true, then event.getValue() would return the old value, prior to modification. If event.isPre() is false, then event.getValue() would return new value. If the event is creating and inserting a new entry, the old value would be null. For more information about isPre() , see the Red Hat JBoss Data Grid API Documentation 's listing for the org.infinispan.notifications.cachelistener.event package. Listeners can only be configured programmatically by using the methods exposed by the Listenable and FilteringListenable interfaces (which the Cache object implements). Report a bug

Commands:
8.89. ibus-table 8.89.1. RHBA-2014:0572 - ibus-table bug fix update Updated ibus-table packages that fix one bug are now available for Red Hat Enterprise Linux 6. The ibus-table packages contain a table engine for Intelligent Input Bus (IBus), which is an input method (IM) framework for multilingual input in Unix-like operating systems. Bug Fix BZ# 983497 Previously, indexing for the compose.db and latex.db files was handled by the post-installation script. As a consequence, running the "rpm -V" command returned an unnecessary warning that the SQLite database files had been changed since the installation. With this update, the indexed files are already included in the packages, and no warning messages are displayed in the described situation. Users of ibus-table are advised to upgrade to these updated packages, which fix this bug.

Commands:
Appendix D. Cephx configuration options The following are Cephx configuration options that can be set up during deployment. auth_cluster_required Description If enabled, the Red Hat Ceph Storage cluster daemons, ceph-mon and ceph-osd , must authenticate with each other. Valid settings are cephx or none . Type String Required No Default cephx . auth_service_required Description If enabled, the Red Hat Ceph Storage cluster daemons require Ceph clients to authenticate with the Red Hat Ceph Storage cluster in order to access Ceph services. Valid settings are cephx or none . Type String Required No Default cephx . auth_client_required Description If enabled, the Ceph client requires the Red Hat Ceph Storage cluster to authenticate with the Ceph client. Valid settings are cephx or none . Type String Required No Default cephx . keyring Description The path to the keyring file. Type String Required No Default /etc/ceph/USDcluster.USDname.keyring,/etc/ceph/USDcluster.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin keyfile Description The path to a key file (that is. a file containing only the key). Type String Required No Default None key Description The key (that is, the text string of the key itself). Not recommended. Type String Required No Default None ceph-mon Location USDmon_data/keyring Capabilities mon 'allow *' ceph-osd Location USDosd_data/keyring Capabilities mon 'allow profile osd' osd 'allow *' radosgw Location USDrgw_data/keyring Capabilities mon 'allow rwx' osd 'allow rwx' cephx_require_signatures Description If set to true , Ceph requires signatures on all message traffic between the Ceph client and the Red Hat Ceph Storage cluster, and between daemons comprising the Red Hat Ceph Storage cluster. Type Boolean Required No Default false cephx_cluster_require_signatures Description If set to true , Ceph requires signatures on all message traffic between Ceph daemons comprising the Red Hat Ceph Storage cluster. Type Boolean Required No Default false cephx_service_require_signatures Description If set to true , Ceph requires signatures on all message traffic between Ceph clients and the Red Hat Ceph Storage cluster. Type Boolean Required No Default false cephx_sign_messages Description If the Ceph version supports message signing, Ceph will sign all messages so they cannot be spoofed. Type Boolean Default true auth_service_ticket_ttl Description When the Red Hat Ceph Storage cluster sends a Ceph client a ticket for authentication, the cluster assigns the ticket a time to live. Type Double Default 60*60 Additional Resources <additional resource 1> <additional resource 2>

Commands: