mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Maintenance procedures 5.1. Updating the OS and HA cluster components Please refer to Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster , for more information. 5.2. Updating the SAP HANA instances If the SAP HANA System Replication setup is managed using the HA cluster configuration described in this document, some additional steps are needed in addition to the actual process of updating the SAP HANA instances before and after the update. Execute the following steps: Put the SAPHana resource in unmanaged mode. [root]# pcs resource unmanage SAPHana_RH1_02-clone Update the SAP HANA instances using the procedure provided by SAP. When the update of the SAP HANA instances has been completed and it has been verified that SAP HANA System Replication is working again, the status of the SAPHana resource needs to be refreshed to make sure the cluster is aware of the current state of the SAP HANA System Replication setup. [root]# pcs resource refresh SAPHana_RH1_02-clone When the HA cluster has correctly picked up the current status of the SAP HANA System Replication setup, put the SAPHana resource back into managed mode so that the HA cluster will be able to react to any issues in the SAP HANA System Replication setup again. [root]# pcs resource manage SAPHana_RH1_02-clone 5.3. Manually moving SAPHana resource to another node (SAP HANA System Replication takeover by HA cluster) A manual takeover of SAP HANA System Replication can be triggered by moving the promotable clone resource: [root]# pcs resource move SAPHana_RH1_02-clone Note pcs-0.10.8-1.el8 or later is required for this command to work correctly. Please refer to The pcs resource move command fails for a promotable clone unless "--master" is specified , for more information. With each pcs resource move command invocation, the HA cluster creates a location constraint to cause the resource to move. Please refer to Is there a way to manage constraints when running pcs resource move? , for more information. This constraint must be removed after it has been verified that the SAP HANA System Replication takeover has been completed in order to allow the HA cluster to manage the former primary SAP HANA instance again. To remove the constraint created by pcs resource move , use the following command: [root]# pcs resource clear SAPHana_RH1_02-clone Note What happens to the former SAP HANA primary instance after the takeover has been completed and the constraint has been removed depends on the setting of the AUTOMATED_REGISTER parameter of the SAPHana resource: If Automated_REGISTER=true , then the former SAP HANA primary instance will be registered as the new secondary and SAP HANA System Replication will become active again. If AUTOMATED_REGISTER=false , then it is up to the operator to decide what should happen with the former SAP HANA primary instance after the takeover.

Commands:
pcs resource unmanage SAPHana_RH1_02-clone
pcs resource refresh SAPHana_RH1_02-clone
pcs resource manage SAPHana_RH1_02-clone
pcs resource move SAPHana_RH1_02-clone
pcs resource clear SAPHana_RH1_02-clone
Chapter 3. Alternative provisioning network methods This section contains information about other methods that you can use to configure the provisioning network to accommodate routed spine-leaf with composable networks. 3.1. VLAN Provisioning network In this example, the director deploys new overcloud nodes through the provisioning network and uses a VLAN tunnel across the L3 topology. For more information, see Figure 3.1, "VLAN provisioning network topology" . If you use a VLAN provisioning network, the director DHCP servers can send DHCPOFFER broadcasts to any leaf. To establish this tunnel, trunk a VLAN between the Top-of-Rack (ToR) leaf switches. In the following diagram, the StorageLeaf networks are presented to the Ceph storage and Compute nodes; the NetworkLeaf represents an example of any network that you want to compose. Figure 3.1. VLAN provisioning network topology 3.2. VXLAN Provisioning network In this example, the director deploys new overcloud nodes through the provisioning network and uses a VXLAN tunnel to span across the layer 3 topology. For more information, see Figure 3.2, "VXLAN provisioning network topology" . If you use a VXLAN provisioning network, the director DHCP servers can send DHCPOFFER broadcasts to any leaf. To establish this tunnel, configure VXLAN endpoints on the Top-of-Rack (ToR) leaf switches. Figure 3.2. VXLAN provisioning network topology

Commands:
9.12.2. Upgrading Using the Installer Note In general, Red Hat recommends that you keep user data on a separate /home partition and perform a fresh installation. For more information on partitions and how to set them up, refer to Section 9.13, "Disk Partitioning Setup" . If you choose to upgrade your system using the installation program, any software not provided by Red Hat Enterprise Linux that conflicts with Red Hat Enterprise Linux software is overwritten. Before you begin an upgrade this way, make a list of your system's current packages for later reference: After installation, consult this list to discover which packages you may need to rebuild or retrieve from sources other than Red Hat. , make a backup of any system configuration data: Make a complete backup of any important data before performing an upgrade. Important data may include the contents of your entire /home directory as well as content from services such as an Apache, FTP, or SQL server, or a source code management system. Although upgrades are not destructive, if you perform one improperly there is a small possibility of data loss. Warning Note that the above examples store backup materials in a /home directory. If your /home directory is not a separate partition, you should not follow these examples verbatim! Store your backups on another device such as CD or DVD discs or an external hard disk. For more information on completing the upgrade process later, refer to Section 35.2, "Finishing an Upgrade" .

Commands:
-qa --qf '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' > ~/old-pkglist.txt
su -c 'tar czf /tmp/etc-`date +%F`.tar.gz /etc' su -c 'mv /tmp/etc-*.tar.gz /home'
Chapter 41. ResourceTemplate schema reference Used in: CruiseControlTemplate , EntityOperatorTemplate , JmxTransTemplate , KafkaBridgeTemplate , KafkaClusterTemplate , KafkaConnectTemplate , KafkaExporterTemplate , KafkaMirrorMakerTemplate , KafkaNodePoolTemplate , KafkaUserTemplate , ZookeeperClusterTemplate Property Property type Description metadata MetadataTemplate Metadata applied to the resource.

Commands:
7.202. ql2400-firmware 7.202.1. RHBA-2013:0402 - ql2400-firmware bug fix and enhancement update An updated ql2400-firmware package that fixes multiple bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The ql2400-firmware package provides the firmware required to run the QLogic 2400 Series of mass storage adapters. Note This update upgrades the ql2400 firmware to upstream version 5.08.00, which provides a number of bug fixes and enhancements over the version. (BZ#826665) All users of QLogic 2400 Series Fibre Channel adapters are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
25.3.2. Adding an LCS Device The LAN channel station (LCS) device driver supports 1000Base-T Ethernet on the OSA-Express2 and OSA-Express 3 features. Based on the type of interface being added, the LCS driver assigns one base interface name: eth n for OSA-Express Fast Ethernet and Gigabit Ethernet n is 0 for the first device of that type, 1 for the second, and so on. 25.3.2.1. Dynamically Adding an LCS Device Load the device driver: Use the cio_ignore command to remove the network channels from the list of ignored devices and make them visible to Linux: Replace read_device_bus_id and write_device_bus_id with the two device bus IDs representing a network device. For example: Create the group device: Configure the device. OSA cards can provide up to 16 ports for a single CHPID. By default, the LCS group device uses port 0 . To use a different port, issue a command similar to the following: Replace portno with the port number you want to use. For more information about configuration of the LCS driver, refer to the chapter on LCS in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6 . Set the device online: To find out what network device name has been assigned, enter the command:

Commands:
modprobe lcs
cio_ignore -r read_device_bus_id , write_device_bus_id
cio_ignore -r 0.0.09a0,0.0.09a1
echo read_device_bus_id , write_device_bus_id > /sys/bus/ccwgroup/drivers/lcs/group
echo portno > /sys/bus/ccwgroup/drivers/lcs/device_bus_id/portno
echo 1 > /sys/bus/ccwgroup/drivers/lcs/read_device_bus_id/online
ls -l /sys/bus/ccwgroup/drivers/lcs/ read_device_bus_ID /net/ drwxr-xr-x 4 root root 0 2010-04-22 16:54 eth1
4.3. Reverting to an Ext2 File System In order to revert to an ext2 file system, use the following procedure. For simplicity, the sample commands in this section use the following value for the block device: /dev/mapper/VolGroup00-LogVol02 Procedure 4.1. Revert from ext3 to ext2 Unmount the partition by logging in as root and typing: Change the file system type to ext2 by typing the following command: Check the partition for errors by typing the following command: Then mount the partition again as ext2 file system by typing: Replace /mount/point with the mount point of the partition. Note If a .journal file exists at the root level of the partition, delete it. To permanently change the partition to ext2, remember to update the /etc/fstab file, otherwise it will revert back after booting.

Commands:
umount /dev/mapper/VolGroup00-LogVol02
tune2fs -O ^has_journal /dev/mapper/VolGroup00-LogVol02
e2fsck -y /dev/mapper/VolGroup00-LogVol02
mount -t ext2 /dev/mapper/VolGroup00-LogVol02 /mount/point
Chapter 14. Using qemu-img The qemu-img command-line tool is used for formatting, modifying, and verifying various file systems used by KVM. qemu-img options and usages are highlighted in the sections that follow. Warning Never use qemu-img to modify images in use by a running virtual machine or any other process. This may destroy the image. Also, be aware that querying an image that is being modified by another process may encounter inconsistent state. 14.1. Checking the Disk Image To perform a consistency check on a disk image with the file name imgname . Note Only a selected group of formats support consistency checks. These include qcow2 , vdi , vhdx , vmdk , and qed .

Commands:
qemu-img check [-f format ] imgname
30.8. Disabling and Enabling sudo Rules Disabling a sudo rule temporarily deactivates it. A disabled rule is not removed from IdM and can be enabled again. Disabling and Enabling sudo Rules from the Web UI Under the Policy tab, click Sudo Sudo Rule . Select the rule to disable and click Disable or Enable . Figure 30.15. Disabling or Enabling a sudo Rule Disabling and Enabling sudo Rules from the Command Line To disable a rule, use the ipa sudo-rule-disable command. To re-enable a rule, use the ipa sudorule-enable command.

Commands:
ipa sudorule-disable sudo_rule_name ----------------------------------- Disabled Sudo Rule "sudo_rule_name" -----------------------------------
ipa sudorule-enable sudo_rule_name ----------------------------------- Enabled Sudo Rule "sudo_rule_name" -----------------------------------
8.9. Configure a Network Team Using the Text User Interface, nmtui The text user interface tool nmtui can be used to configure teaming in a terminal window. Issue the following command to start the tool: The text user interface appears. Any invalid command prints a usage message. To navigate, use the arrow keys or press Tab to step forwards and press Shift + Tab to step back through the options. Press Enter to select an option. The Space bar toggles the status of a check box. From the starting menu, select Edit a connection . Select Add , the New Connection screen opens. Figure 8.1. The NetworkManager Text User Interface Add a Team Connection menu Select Team , the Edit connection screen opens. Figure 8.2. The NetworkManager Text User Interface Configuring a Team Connection menu To add port interfaces to the team select Add , the New Connection screen opens. Once the type of Connection has been chosen select the Create button to cause the team's Edit Connection display to appear. Figure 8.3. The NetworkManager Text User Interface Configuring a new Team Port Interface Connection menu Enter the required port's device name or MAC address in the Device section. If required, enter a clone MAC address to be used as the team's MAC address by selecting Show to the right of the Ethernet label. Select the OK button. Note If the device is specified without a MAC address the Device section will be automatically populated once the Edit Connection window is reloaded, but only if it successfully finds the device. Figure 8.4. The NetworkManager Text User Interface Configuring a Team's Port Interface Connection menu The name of the teamed port appears in the Slaves section. Repeat the above steps to add further port connections. If custom port settings are to be applied select the Edit button under the JSON configuration section. This will launch a vim console where changes may be applied. Once finished write the changes from vim and then confirm that the displayed JSON string under JSON configuration matches what is intended. Review and confirm the settings before selecting the OK button. Figure 8.5. The NetworkManager Text User Interface Configuring a Team Connection menu See Section 8.13, "Configure teamd Runners" for examples of JSON strings. Note that only the relevant sections from the example strings should be used for a team or port configuration using nmtui . Do not specify the " Device " as part of the JSON string. For example, only the JSON string after " device " but before " port " should be used in the Team JSON configuration field. All JSON strings relevant to a port must only be added in the port configuration field. See Section 3.2, "Configuring IP Networking with nmtui" for information on installing nmtui .

Commands:
~]USD nmtui
Preface The Red Hat build of Cryostat is a container-native implementation of JDK Flight Recorder (JFR) that you can use to securely monitor the Java Virtual Machine (JVM) performance in workloads that run on an OpenShift Container Platform cluster. You can use Cryostat 2.4 to start, stop, retrieve, archive, import, and export JFR data for JVMs inside your containerized applications by using a web console or an HTTP API. Depending on your use case, you can store and analyze your recordings directly on your Red Hat OpenShift cluster by using the built-in tools that Cryostat provides or you can export recordings to an external monitoring application to perform a more in-depth analysis of your recorded data. Important Red Hat build of Cryostat is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope .

Commands:
Part V. Functional certification for OpenShift badges: Virtualization, Best practices, CNF, CNI, CSI Red Hat OpenShift certification badges extend the Red Hat OpenShift Operator certification. The certification badges are built on the foundation of container and operator certifications. By receiving a Red Hat OpenShift Certification Badge, partners can confirm that their solution is Kubernetes enabled, meets Kubernetes best practices and utilizes specific Kubernetes APIs for addressing the respective use cases. The current OpenShift certification badges that are available are as follows: OpenShift Virtualization - for providing support to run and manage virtual machine workloads on Red Hat OpenShift. Meets Best practices -for meeting the Red Hat best practices checkpoints for cloud native software products that are deployed on Red Hat OpenShift. Cloud-Native Network Functions (CNF) -for the implementation of telecommunication functions deployed as containers. Container Networking Interface (CNI) -for the delivery of networking services through a pluggable framework. Container Storage Interface (CSI) -for providing and supporting a block or file persistent storage backend for Red Hat OpenShift.

Commands:
Chapter 103. ZipArtifact schema reference Used in: Plugin Property Property type Description type string Must be zip . url string URL of the artifact which will be downloaded. Streams for Apache Kafka does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for jar , zip , tgz and other artifacts. Not applicable to the maven artifact type. sha512sum string SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the maven artifact type. insecure boolean By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to true , all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.

Commands:
6.2. Web UI: Using the Topology Graph to Manage Replication Topology Accessing the Topology Graph The topology graph in the web UI shows the relationships between the servers in the domain: Select IPA Server Topology Topology Graph . If you make any changes to the topology that are not immediately reflected in the graph, click Refresh . Customizing the Topology View You can move individual topology nodes by dragging the mouse: Figure 6.3. Moving Topology Graph Nodes You can zoom in and zoom out the topology graph using the mouse wheel: Figure 6.4. Zooming the Topology Graph You can move the canvas of the topology graph by holding the left mouse button: Figure 6.5. Moving the Topology Graph Canvas Interpreting the Topology Graph Servers joined in a domain replication agreement are connected by an orange arrow. Servers joined in a CA replication agreement are connected by a blue arrow. Topology graph example: recommended topology Figure 6.6, "Recommended Topology Example" shows one of the possible recommended topologies for four servers: each server is connected to at least two other servers, and more than one server is a CA master. Figure 6.6. Recommended Topology Example Topology graph example: discouraged topology In Figure 6.7, "Discouraged Topology Example: Single Point of Failure" , server1 is a single point of failure. All the other servers have replication agreements with this server, but not with any of the other servers. Therefore, if server1 fails, all the other servers will become isolated. Avoid creating topologies like this. Figure 6.7. Discouraged Topology Example: Single Point of Failure For details on topology recommendations, see Section 4.2, "Deployment Considerations for Replicas" . 6.2.1. Setting up Replication Between Two Servers In the topology graph, hover your mouse over one of the server nodes. Figure 6.8. Domain or CA Options Click on the domain or the ca part of the circle depending on what type of topology segment you want to create. A new arrow representing the new replication agreement appears under your mouse pointer. Move your mouse to the other server node, and click on it. Figure 6.9. Creating a New Segment In the Add Topology Segment window, click Add to confirm the properties of the new segment. IdM creates a new topology segment between the two servers, which joins them in a replication agreement. The topology graph now shows the updated replication topology: Figure 6.10. New Segment Created 6.2.2. Stopping Replication Between Two Servers Click on an arrow representing the replication agreement you want to remove. This highlights the arrow. Figure 6.11. Topology Segment Highlighted Click Delete . In the Confirmation window, click OK . IdM removes the topology segment between the two servers, which deletes their replication agreement. The topology graph now shows the updated replication topology: Figure 6.12. Topology Segment Deleted

Commands:
6.5. Resource Groups One of the most common elements of a cluster is a set of resources that need to be located together, start sequentially, and stop in the reverse order. To simplify this configuration, Pacemaker supports the concept of groups. You create a resource group with the following command, specifying the resources to include in the group. If the group does not exist, this command creates the group. If the group exists, this command adds additional resources to the group. The resources will start in the order you specify them with this command, and will stop in the reverse order of their starting order. You can use the --before and --after options of this command to specify the position of the added resources relative to a resource that already exists in the group. You can also add a new resource to an existing group when you create the resource, using the following command. The resource you create is added to the group named group_name . You remove a resource from a group with the following command. If there are no resources in the group, this command removes the group itself. The following command lists all currently configured resource groups. The following example creates a resource group named shortcut that contains the existing resources IPaddr and Email . There is no limit to the number of resources a group can contain. The fundamental properties of a group are as follows. Resources are started in the order in which you specify them (in this example, IPaddr first, then Email ). Resources are stopped in the reverse order in which you specify them. ( Email first, then IPaddr ). If a resource in the group cannot run anywhere, then no resource specified after that resource is allowed to run. If IPaddr cannot run anywhere, neither can Email . If Email cannot run anywhere, however, this does not affect IPaddr in any way. Obviously as the group grows bigger, the reduced configuration effort of creating resource groups can become significant. 6.5.1. Group Options A resource group inherits the following options from the resources that it contains: priority , target-role , is-managed . For information on resource options, see Table 6.3, "Resource Meta Options" . 6.5.2. Group Stickiness Stickiness, the measure of how much a resource wants to stay where it is, is additive in groups. Every active resource of the group will contribute its stickiness value to the group's total. So if the default resource-stickiness is 100, and a group has seven members, five of which are active, then the group as a whole will prefer its current location with a score of 500.

Commands:
pcs resource group add group_name resource_id [ resource_id ] ... [ resource_id ] [--before resource_id | --after resource_id ]
pcs resource create resource_id standard:provider:type|type [resource_options] [op operation_action operation_options ] --group group_name
pcs resource group remove group_name resource_id
pcs resource group list
pcs resource group add shortcut IPaddr Email