mtpti5iD/redhat-docs_dataset huggingface dataset:
5.2.11. /proc/interrupts This file records the number of interrupts per IRQ on the x86 architecture. A standard /proc/interrupts looks similar to the following: For a multi-processor machine, this file may look slightly different: The first column refers to the IRQ number. Each CPU in the system has its own column and its own number of interrupts per IRQ. The column reports the type of interrupt, and the last column contains the name of the device that is located at that IRQ. Each of the types of interrupts seen in this file, which are architecture-specific, mean something different. For x86 machines, the following values are common: XT-PIC - This is the old AT computer interrupts. IO-APIC-edge - The voltage signal on this interrupt transitions from low to high, creating an edge , where the interrupt occurs and is only signaled once. This kind of interrupt, as well as the IO-APIC-level interrupt, are only seen on systems with processors from the 586 family and higher. IO-APIC-level - Generates interrupts when its voltage signal is high until the signal is low again.

Commands:
CPU0 0: 80448940 XT-PIC timer 1: 174412 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 10: 410964 XT-PIC eth0 12: 60330 XT-PIC PS/2 Mouse 14: 1314121 XT-PIC ide0 15: 5195422 XT-PIC ide1 NMI: 0 ERR: 0
CPU0 CPU1 0: 1366814704 0 XT-PIC timer 1: 128 340 IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 1 IO-APIC-edge rtc 12: 5323 5793 IO-APIC-edge PS/2 Mouse 13: 1 0 XT-PIC fpu 16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro 10/100 Ethernet 20: 8450043 11120093 IO-APIC-level megaraid 30: 10432 10722 IO-APIC-level aic7xxx 31: 23 22 IO-APIC-level aic7xxx NMI: 0 ERR: 0
4.18. HP Moonshot iLO Table 4.19, "HP Moonshot iLO (Red Hat Enterprise Linux 6.7 and later)" lists the fence device parameters used by fence_ilo_moonshot , the fence agent for HP Moonshot iLO devices. Table 4.19. HP Moonshot iLO (Red Hat Enterprise Linux 6.7 and later) luci Field cluster.conf Attribute Description Name name A name for the server with HP iLO support. IP Address or Hostname ipaddr The IP address or host name assigned to the device. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. Use SSH secure Indicates that the system will use SSH to access the device. When using SSH, you must specify either a password, a password script, or an identity file. Path to SSH Identity File identity_file The Identity file for SSH. TCP Port ipport UDP/TCP port to use for connections with the device; the default value is 22. Force Command Prompt cmd_prompt The command prompt to use. The default value is 'MP>', 'hpiLO->'. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Delay (seconds) delay The number of seconds to wait before fencing is started. The default value is 0. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1.

Commands:
Part IX. Decision engine in Red Hat Process Automation Manager As a business rules developer, your understanding of the decision engine in Red Hat Process Automation Manager can help you design more effective business assets and a more scalable decision management architecture. The decision engine is the Red Hat Process Automation Manager component that stores, processes, and evaluates data to execute business rules and to reach the decisions that you define. This document describes basic concepts and functions of the decision engine to consider as you create your business rule system and decision services in Red Hat Process Automation Manager.

Commands:
13.2. The Benefits of Using Hot Rod over Memcached Red Hat JBoss Data Grid offers a choice of protocols for allowing clients to interact with the server in a Remote Client-Server environment. When deciding between using memcached or Hot Rod, the following should be considered. Memcached The memcached protocol causes the server endpoint to use the memcached text wire protocol . The memcached wire protocol has the benefit of being commonly used, and is available for almost any platform. All of JBoss Data Grid's functions, including clustering, state sharing for scalability, and high availability, are available when using memcached. However the memcached protocol lacks dynamicity, resulting in the need to manually update the list of server nodes on your clients in the event one of the nodes in a cluster fails. Also, memcached clients are not aware of the location of the data in the cluster. This means that they will request data from a non-owner node, incurring the penalty of an additional request from that node to the actual owner, before being able to return the data to the client. This is where the Hot Rod protocol is able to provide greater performance than memcached. Hot Rod JBoss Data Grid's Hot Rod protocol is a binary wire protocol that offers all the capabilities of memcached, while also providing better scaling, durability, and elasticity. The Hot Rod protocol does not need the hostnames and ports of each node in the remote cache, whereas memcached requires these parameters to be specified. Hot Rod clients automatically detect changes in the topology of clustered Hot Rod servers; when new nodes join or leave the cluster, clients update their Hot Rod server topology view. Consequently, Hot Rod provides ease of configuration and maintenance, with the advantage of dynamic load balancing and failover. Additionally, the Hot Rod wire protocol uses smart routing when connecting to a distributed cache. This involves sharing a consistent hash algorithm between the server nodes and clients, resulting in faster read and writing capabilities than memcached. Warning When using JCache over Hot Rod it is not possible to create remote clustered caches, as the operation is executed on a single node as opposed to the entire cluster; however, once a cache has been created on the cluster it may be obtained using the cacheManager.getCache method. It is recommended to create caches using either configuration files, JON, or the CLI. Report a bug

Commands:
Chapter 132. AutoRestart schema reference Used in: KafkaConnectorSpec , KafkaMirrorMaker2ConnectorSpec Full list of AutoRestart schema properties Configures automatic restarts for connectors and tasks that are in a FAILED state. When enabled, a back-off algorithm applies the automatic restart to each failed connector and its tasks. The operator attempts an automatic restart on reconciliation. If the first attempt fails, the operator makes up to six more attempts. The duration between each restart attempt increases from 2 to 30 minutes. After each restart, failed connectors and tasks transit from FAILED to RESTARTING . If the restart fails after the final attempt, there is likely to be a problem with the connector configuration. The connector and tasks remain in a FAILED state and you have to restart them manually. You can do this by annotating the KafKaConnector custom resource with strimzi.io/restart: "true" . For Kafka Connect connectors, use the autoRestart property of the KafkaConnector resource to enable automatic restarts of failed connectors and tasks. Enabling automatic restarts of failed connectors for Kafka Connect apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true For MirrorMaker 2, use the autoRestart property of connectors in the KafkaMirrorMaker2 resource to enable automatic restarts of failed connectors and tasks. Enabling automatic restarts of failed connectors for MirrorMaker 2 apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mm2-cluster spec: mirrors: - sourceConnector: autoRestart: enabled: true # ... heartbeatConnector: autoRestart: enabled: true # ... checkpointConnector: autoRestart: enabled: true # ... 132.1. AutoRestart schema properties Property Description enabled Whether automatic restart for failed connectors and tasks should be enabled or disabled. boolean

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mm2-cluster spec: mirrors: - sourceConnector: autoRestart: enabled: true # heartbeatConnector: autoRestart: enabled: true # checkpointConnector: autoRestart: enabled: true #
probe::scsi.iocompleted Name probe::scsi.iocompleted - SCSI mid-layer running the completion processing for block device I/O requests Synopsis Values device_state_str The current state of the device, as a string dev_id The scsi device id channel The channel number data_direction The data_direction specifies whether this command is from/to the device lun The lun number host_no The host number data_direction_str Data direction, as a string device_state The current state of the device req_addr The current struct request pointer, as a number goodbytes The bytes completed

Commands:
scsi.iocompleted
Appendix G. System Accounts G.1. System Accounts G.1.1. Red Hat Virtualization Manager User Accounts A number of system user accounts are created to support Red Hat Virtualization when the rhevm package is installed. Each system user has a default user identifier (UID). The system user accounts created are: The vdsm user (UID 36 ). Required for support tools that mount and access NFS storage domains. The ovirt user (UID 108 ). Owner of the ovirt-engine Red Hat JBoss Enterprise Application Platform instance. The ovirt-vmconsole user (UID 498 ). Required for the guest serial console. G.1.2. Red Hat Virtualization Manager Groups A number of system user groups are created to support Red Hat Virtualization when the rhevm package is installed. Each system user group has a default group identifier (GID). The system user groups created are: The kvm group (GID 36 ). Group members include: The vdsm user. The ovirt group (GID 108 ). Group members include: The ovirt user. The ovirt-vmconsole group (GID 498 ). Group members include: The ovirt-vmconsole user. G.1.3. Virtualization Host User Accounts A number of system user accounts are created on the virtualization host when the vdsm and qemu-kvm-rhev packages are installed. Each system user has a default user identifier (UID). The system user accounts created are: The vdsm user (UID 36 ). The qemu user (UID 107 ). The sanlock user (UID 179 ). The ovirt-vmconsole user (UID 498 ). Important The user identifiers (UIDs) and group identifiers (GIDs) allocated may vary between systems. The vdsm user is fixed to a UID of 36 and the kvm group is fixed to a GID of 36 . If UID 36 or GID 36 is already used by another account on the system a conflict will arise during installation of the vdsm and qemu-kvm-rhev packages. G.1.4. Virtualization Host Groups A number of system user groups are created on the virtualization host when the vdsm and qemu-kvm-rhev packages are installed. Each system user group has a default group identifier (GID). The system user groups created are: The kvm group (GID 36 ). Group members include: The qemu user. The sanlock user. The qemu group (GID 107 ). Group members include: The vdsm user. The sanlock user. The ovirt-vmconsole group (GID 498 ). Group members include: The ovirt-vmconsole user. Important The user identifiers (UIDs) and group identifiers (GIDs) allocated may vary between systems. The vdsm user is fixed to a UID of 36 and the kvm group is fixed to a GID of 36 . If UID 36 or GID 36 is already used by another account on the system a conflict will arise during installation of the vdsm and qemu-kvm-rhev packages.

Commands:
Chapter 5. Downgrading Red Hat Quay Red Hat Quay only supports rolling back, or downgrading, to z-stream versions, for example, 3.7.2 3.7.1. Rolling back to y-stream versions (3.7.0 3.6.0) is not supported. This is because Red Hat Quay updates might contain database schema upgrades that are applied when upgrading to a new version of Red Hat Quay. Database schema upgrades are not considered backwards compatible. Important Downgrading to z-streams is neither recommended nor supported by either Operator based deployments or virtual machine based deployments. Downgrading should only be done in extreme circumstances. The decision to rollback your Red Hat Quay deployment must be made in conjunction with the Red Hat Quay support and development teams. For more information, contact Red Hat Quay support.

Commands:
C.9. Glock Statistics GFS2 maintains statistics that can help track what is going on within the file system. This allows you to spot performance issues. GFS2 maintains two counters: dcount , which counts the number of DLM operations requested. This shows how much data has gone into the mean/variance calculations. qcount , which counts the number of syscall level operations requested. Generally qcount will be equal to or greater than dcount . In addition, GFS2 maintains three mean/variance pairs. The mean/variance pairs are smoothed exponential estimates and the algorithm used is the one used to calculate round trip times in network code. The mean and variance pairs maintained in GFS2 are not scaled, but are in units of integer nanoseconds. srtt/srttvar: Smoothed round trip time for non-blocking operations srttb/srttvarb: Smoothed round trip time for blocking operations irtt/irttvar: Inter-request time (for example, time between DLM requests) A non-blocking request is one which will complete right away, whatever the state of the DLM lock in question. That currently means any requests when (a) the current state of the lock is exclusive (b) the requested state is either null or unlocked or (c) the "try lock" flag is set. A blocking request covers all the other lock requests. Larger times are better for IRTTs, whereas smaller times are better for the RTTs. Statistics are kept in two sysfs files: The glstats file. This file is similar to the glocks file, except that it contains statistics, with one glock per line. The data is initialized from "per cpu" data for that glock type for which the glock is created (aside from counters, which are zeroed). This file may be very large. The lkstats file. This contains "per cpu" stats for each glock type. It contains one statistic per line, in which each column is a cpu core. There are eight lines per glock type, with types following on from each other.

Commands:
2.2.4.3. Beware of Syntax Errors The NFS server determines which file systems to export and which hosts to export these directories to by consulting the /etc/exports file. Be careful not to add extraneous spaces when editing this file. For instance, the following line in the /etc/exports file shares the directory /tmp/nfs/ to the host bob.example.com with read/write permissions. The following line in the /etc/exports file, on the other hand, shares the same directory to the host bob.example.com with read-only permissions and shares it to the world with read/write permissions due to a single space character after the hostname. It is good practice to check any configured NFS shares by using the showmount command to verify what is being shared: showmount -e <hostname>

Commands:
/tmp/nfs/ bob.example.com(rw)
/tmp/nfs/ bob.example.com (rw)
Chapter 6. Attaching your Red Hat Ansible Automation Platform subscription You must have valid subscriptions attached on all nodes before installing Red Hat Ansible Automation Platform. Attaching your Ansible Automation Platform subscription allows you to access subcription-only resources necessary to proceed with the installation. Note Attaching a subscription is unnecessary if you have enabled Simple Content Access Mode on your Red Hat account. Once enabled, you will need to register your systems to either Red Hat Subscription Management (RHSM) or Satellite before installing the Ansible Automation Platform. See Simple Content Access Mode for more information. Procedure Obtain the pool_id for your Red Hat Ansible Automation Platform subscription: # subscription-manager list --available --all | grep "Ansible Automation Platform" -B 3 -A 6 Note Do not use MCT4022 as a pool_id for your subscription because it can cause Ansible Automation Platform subscription attachment to fail. Example An example output of the subsciption-manager list command. Obtain the pool_id as seen in the Pool ID: section: Subscription Name: Red Hat Ansible Automation, Premium (5000 Managed Nodes) Provides: Red Hat Ansible Engine Red Hat Ansible Automation Platform SKU: MCT3695 Contract: ```` Pool ID: <pool_id> Provides Management: No Available: 4999 Suggested: 1 Attach the subscription: # subscription-manager attach --pool=<pool_id> You have now attached your Red Hat Ansible Automation Platform subscriptions to all nodes. Verification Verify the subscription was successfully attached: # subscription-manager list --consumed Troubleshooting If you are unable to locate certain packages that came bundled with the Ansible Automation Platform installer, or if you are seeing a Repositories disabled by configuration message, try enabling the repository using the command: Red Hat Ansible Automation Platform 2.3 for RHEL 8 subscription-manager repos --enable ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms Red Hat Ansible Automation Platform 2.3 for RHEL 9 subscription-manager repos --enable ansible-automation-platform-2.3-for-rhel-9-x86_64-rpms

Commands:
subscription-manager list --available --all | grep "Ansible Automation Platform" -B 3 -A 6
Subscription Name: Red Hat Ansible Automation, Premium (5000 Managed Nodes) Provides: Red Hat Ansible Engine Red Hat Ansible Automation Platform SKU: MCT3695 Contract: ```` Pool ID: <pool_id> Provides Management: No Available: 4999 Suggested: 1
subscription-manager attach --pool=<pool_id>
subscription-manager list --consumed
subscription-manager repos --enable ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms
subscription-manager repos --enable ansible-automation-platform-2.3-for-rhel-9-x86_64-rpms
Chapter 5. Known issues Sometimes a Cryostat release might contain an issue or issues that Red Hat acknowledges and might fix at a later stage during the product's development. Review each known issue for its description and its resolution. Cryostat agent cannot accept the ALL event template in recording start requests Description When creating a JFR recording for a target JVM that is using the Cryostat agent, if you select the ALL event template, the Cryostat agent returns an HTTP 400 error. Workaround Depending on your requirements, you can do either of the following: If you want to use the ALL event template, use a JMX connection with your target JVM. If you want to use a Cryostat agent connection with your target JVM, use a different event template such as Profiling. Red Hat Insights integration fails on ARM64 architecture Description In the Cryostat Operator's namespace, a pod whose name begins with insights-proxy is in the ImagePullBackOff error state. This is because the APICast container used for this pod is not built for the ARM64 architecture. However, Cryostat and all applications that are using the Cryostat agent should still function normally. Workaround To disable Red Hat Insights integration: Navigate to Operators > Installed Operators . Select the Red Hat build of Cryostat operator. Select the Subscription tab. From the Actions drop-down menu, select Edit Subscription . Add the INSIGHTS_ENABLED environment variable to the Subscription object: Click Save . This workaround disables Red Hat Insights integration in the Cryostat Operator, which removes the insights-proxy deployment.

Commands:
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cryostat-operator namespace: openshift-operators spec: config: env: - name: INSIGHTS_ENABLED value: "false" channel: stable installPlanApproval: Automatic name: cryostat-operator source: my-operator-catalog sourceNamespace: openshift-marketplace startingCSV: cryostat-operator.v2.4.0
Providing feedback on Red Hat documentation We appreciate your input on our documentation. Please let us know how we could make it better. For simple comments on specific passages: Ensure you are viewing the documentation in the HTML format. In addition, ensure you see the Feedback button in the upper right corner of the document. Use your mouse cursor to highlight the part of text that you want to comment on. Click the Add Feedback pop-up that appears below the highlighted text. Follow the displayed instructions. For submitting feedback via Bugzilla, create a new ticket: Go to the Bugzilla website. As the Component, use Documentation . Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation. Click Submit Bug .

Commands:
Chapter 5. Configuring the Nagios Plugins for Ceph Configure the Nagios plug-ins for Red Hat Ceph Storage cluster. Prerequisites User-level access to the Ceph Monitor node. A running Red Hat Ceph Storage cluster. Access to the Nagios Core Server. Procedure Log in to the monitor server and create a Ceph key and keyring for Nagios. Each plug-in will require authentication. Repeat this procedure for each node that contains a plug-in. Add a command for the check_ceph_health plug-in: Example Enable and restart the nrpe service: Repeat this procedure for each Ceph plug-in applicable to the node. Return to the Nagios Core server and define a check_nrpe command for the NRPE plug-in: On the Nagios Core server, edit the configuration file for the node and add a service for the Ceph plug-in. Example Note The check_command setting uses check_nrpe! before the Ceph plug-in name. This tells NRPE to execute the check_ceph_health command on the remote node. Repeat this procedure for each plug-in applicable to the node. Restart the Nagios Core server: Before proceeding with additional configuration, ensure that the plug-ins are working. Example Note The check_ceph_health plug-in performs the equivalent of the ceph health command. Additional Resources See the Ceph Nagios plugins web page for usage.

Commands:
ssh mon cd /etc/ceph ceph auth get-or-create client.nagios mon 'allow r' > client.nagios.keyring
vi /usr/local/nagios/etc/nrpe.cfg
command[check_ceph_health]=/usr/lib/nagios/plugins/check_ceph_health --id nagios --keyring /etc/ceph/client.nagios.keyring
systemctl enable nrpe systemctl restart nrpe
cd /usr/local/nagios/etc/objects vi commands.cfg
define command{ command_name check_nrpe command_line USER1 /check_nrpe -H HOSTADDRESS -c ARG1 }
vi /usr/local/nagios/etc/objects/mon.cfg
define service { use generic-service host_name mon service_description Ceph Health Check check_command check_nrpe!check_ceph_health }
systemctl restart nagios
/usr/lib/nagios/plugins/check_ceph_health --id nagios --keyring /etc/ceph/client.nagios.keyring
2.12. Saving the File To review the contents of the kickstart file after you have finished choosing your kickstart options, select File => Preview from the pull-down menu. Figure 2.17. Preview To save the kickstart file, click the Save to File button in the preview window. To save the file without previewing it, select File => Save File or press Ctrl + S . A dialog box appears. Select where to save the file. After saving the file, refer to Section 1.10, "Starting a Kickstart Installation" for information on how to start the kickstart installation.

Commands: