mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 39. Modifying Link Loss Behavior This section describes how to modify the link loss behavior of devices that use either fibre channel or iSCSI protocols. 39.1. Fibre Channel If a driver implements the Transport dev_loss_tmo callback, access attempts to a device through a link will be blocked when a transport problem is detected. To verify if a device is blocked, run the following command: This command will return blocked if the device is blocked. If the device is operating normally, this command will return running . Procedure 39.1. Determining The State of a Remote Port To determine the state of a remote port, run the following command: This command will return Blocked when the remote port (along with devices accessed through it) are blocked. If the remote port is operating normally, the command will return Online . If the problem is not resolved within dev_loss_tmo seconds, the rport and devices will be unblocked and all I/O running on that device (along with any new I/O sent to that device) will be failed. Procedure 39.2. Changing dev_loss_tmo To change the dev_loss_tmo value, echo in the desired value to the file. For example, to set dev_loss_tmo to 30 seconds, run: For more information about dev_loss_tmo , refer to Section 26.1, "Fibre Channel API" . When a link or target port loss exceeds dev_loss_tmo , the scsi_device and sd N devices are removed. The target port SCSI ID binding is saved. When the target returns, the SCSI address and sd N assignments may be changed. The SCSI address will change if there has been any LUN configuration changes behind the target port. The sd N names may change depending on timing variations during the LUN discovery process or due to LUN configuration change within storage. These assignments are not persistent as described in Chapter 28, Persistent Naming . Refer to section Chapter 28, Persistent Naming for alternative device naming methods that are persistent.

Commands:
cat /sys/block/ device /device/state
cat /sys/class/fc_remote_port/rport- H : B : R /port_state
echo 30 > /sys/class/fc_remote_port/rport- H : B : R /dev_loss_tmo
2.3. Automatic Kerberos Host Keytab Renewal SSSD automatically renews the Kerberos host keytab file in an AD environment if the adcli package is installed. The daemon checks daily if the machine account password is older than the configured value and renews it if necessary. The default renewal interval is 30 days. To change the default: Add the following parameter to the AD provider in your /etc/sssd/sssd.conf file: Restart SSSD: To disable the automatic Kerberos host keytab renewal, set ad_maximum_machine_account_password_age = 0 .

Commands:
ad_maximum_machine_account_password_age = value_in_days
systemctl restart sssd
6.2. Default Log File Locations These are the log files that get created for the default logging configurations. The default configuration writes the server log files using periodic log handlers. Table 6.1. Default Log File for a standalone server Log File Description EAP_HOME /standalone/log/server.log Server Log. Contains all server log messages, including server startup messages. EAP_HOME /standalone/log/gc.log Garbage collection log. Contains details of all garbage collection. Table 6.2. Default Log Files for a managed domain Log File Description EAP_HOME /domain/log/host-controller.log Host Controller boot log. Contains log messages related to the startup of the host controller. EAP_HOME /domain/log/process-controller.log Process controller boot log. Contains log messages related to the startup of the process controller. EAP_HOME /domain/servers/ SERVERNAME /log/server.log The server log for the named server. Contains all log messages for that server, including server startup messages.

Commands:
Chapter 5. Running Red Hat JBoss Data Virtualization 5.1. Starting JBoss Data Virtualization You can run JBoss Data Virtualization by starting the JBoss EAP server . To start the JBoss EAP server : Red Hat Enterprise Linux Open a terminal and enter the command: USD EAP_HOME /bin/standalone.sh Microsoft Windows Open a terminal and enter the command: USD EAP_HOME \bin\standalone.bat Note To verify that there have been no errors, check the server log: EAP_HOME / MODE /log/server.log . You can also verify this by opening the Management Console and logging in using the username and password of a registered JBoss EAP Management User.

Commands:
Chapter 7. Uninstalling a cluster on vSphere that uses installer-provisioned infrastructure You can remove a cluster that you deployed in your VMware vSphere instance by using installer-provisioned infrastructure. Note When you run the openshift-install destroy cluster command to uninstall OpenShift Container Platform, vSphere volumes are not automatically deleted. The cluster administrator must manually find the vSphere volumes and delete them. 7.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
Chapter 8. October 2023 8.1. Changes to settings We made several changes to the UI that affect how to update your cost management settings. Before, you updated your settings in the Red Hat Hybrid Cloud Console settings page. With this update, cost management has its own settings page . 8.1.1. Configuring cost management You can configure cost management from a few different locations on Red Hat Hybrid Cloud Console : From the Red Hat Hybrid Cloud Console Settings , you can configure the following: Adding and editing cloud integrations Notifications From the Identity & Access Management settings, you can configure the following: User access Authentication policy From the cost management settings , you can configure the following: Enablement, grouping, and filtering of Tags and Labels Enablement of AWS cost categories Your preferred currency calculation Your preferred savings plan or subscription fee calculation for AWS

Commands:
D.21. Cheat Sheets View To open Cheat Sheets View , click the main menu's Window > Show View > Other... and then click the Help > Cheat Sheets view in the dialog. The Cheat Sheets view is a standard Eclipse Help concept. Cheat Sheets provide step by step assistance for common process workflows. Teiid Designer has contributed to the Eclipse help framework to provide assistance for many common modeling tasks. The Guides View (see Guides View) provides links to these Cheat Sheets, as previously described. A sample Cheat Sheet is shown below: Figure D.33. Cheat Sheet Sample

Commands:
12.2. Red Hat Gluster Storage Component Logs and Location The table lists the component, services, and functionality based logs in the Red Hat Gluster Storage Server. As per the File System Hierarchy Standards (FHS) all the log files are placed in the /var/log directory. Table 12.1. Component/Service Name Location of the Log File Remarks glusterd /var/log/glusterfs/glusterd.log One glusterd log file per server. This log file also contains the snapshot and user logs. gluster commands /var/log/glusterfs/cmd_history.log Gluster commands executed on a node in a Red Hat Gluster Storage Trusted Storage Pool is logged in this file. bricks /var/log/glusterfs/bricks/ <path extraction of brick path> .log One log file per brick on the server rebalance /var/log/glusterfs/ VOLNAME -rebalance.log One log file per volume on the server self heal deamon /var/log/glusterfs/glustershd.log One log file per server quota (Deprecated) See Chapter 9, Managing Directory Quotas for more details. /var/log/glusterfs/quotad.log Log of the quota daemons running on each node. /var/log/glusterfs/quota-crawl.log Whenever quota is enabled, a file system crawl is performed and the corresponding log is stored in this file /var/log/glusterfs/quota-mount- VOLNAME .log An auxiliary FUSE client is mounted in <gluster-run-dir>/ VOLNAME of the glusterFS and the corresponding client logs found in this file. One log file per server (and per volume from quota-mount. Gluster NFS (Deprecated) /var/log/glusterfs/nfs.log One log file per server SAMBA Gluster /var/log/samba/glusterfs- VOLNAME -<ClientIP>.log If the client mounts this on a glusterFS server node, the actual log file or the mount point may not be found. In such a case, the mount outputs of all the glusterFS type mount operations need to be considered. NFS - Ganesha /var/log/ganesha/ganesha.log , /var/log/ganesha/ganesha-gfapi.log One log file per server FUSE Mount /var/log/ glusterfs/ <mountpoint path extraction> .log Geo-replication /var/log/glusterfs/geo-replication/<master> /var/log/glusterfs/geo-replication-slaves gluster volume heal VOLNAME info command /var/log/glusterfs/glfsheal- VOLNAME .log One log file per server on which the command is executed. SwiftKrbAuth (Deprecated) /var/log/httpd/error_log Command Line Interface logs /var/log/glusterfs/ cli .log This file captures log entries for every command that is executed on the Command Line Interface(CLI).

Commands:
Providing feedback on Red Hat documentation We appreciate your input on our documentation. Tell us how we can make it better. Providing documentation feedback in Jira Use the Create Issue form to provide feedback on the documentation for Red Hat OpenStack Services on OpenShift (RHOSO) or earlier releases of Red Hat OpenStack Platform (RHOSP). When you create an issue for RHOSO or RHOSP documents, the issue is recorded in the RHOSO Jira project, where you can track the progress of your feedback. To complete the Create Issue form, ensure that you are logged in to Jira. If you do not have a Red Hat Jira account, you can create an account at https://issues.redhat.com . Click the following link to open a Create Issue page: Create Issue Complete the Summary and Description fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form. Click Create .

Commands:
probe::signal.send.return Name probe::signal.send.return - Signal being sent to a process completed (deprecated in SystemTap 2.1) Synopsis signal.send.return Values shared Indicates whether the sent signal is shared by the thread group. name The name of the function used to send out the signal retstr The return value to either __group_send_sig_info, specific_send_sig_info, or send_sigqueue send2queue Indicates whether the sent signal was sent to an existing sigqueue Context The signal's sender. (correct?) Description Possible __group_send_sig_info and specific_send_sig_info return values are as follows; 0 -- The signal is successfully sent to a process, which means that, (1) the signal was ignored by the receiving process, (2) this is a non-RT signal and the system already has one queued, and (3) the signal was successfully added to the sigqueue of the receiving process. -EAGAIN -- The sigqueue of the receiving process is overflowing, the signal was RT, and the signal was sent by a user using something other than kill . Possible send_group_sigqueue and send_sigqueue return values are as follows; 0 -- The signal was either successfully added into the sigqueue of the receiving process, or a SI_TIMER entry is already queued (in which case, the overrun count will be simply incremented). 1 -- The signal was ignored by the receiving process. -1 -- (send_sigqueue only) The task was marked exiting, allowing * posix_timer_event to redirect it to the group leader.

Commands:
10.3. GDB In Red Hat Enterprise Linux 7, the GDB debugger is based on the gdb-7.6.1 release, and includes numerous enhancements and bug fixes relative to the Red Hat Enterprise Linux 6 equivalent. This version corresponds to GDB in Red Hat Developer Toolset 2.1; a detailed comparison of Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 GDB versions can be seen here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/User_Guide/index.html Notable new features of GDB included in Red Hat Enterprise Linux 7 are the following: Faster loading of symbols using the new .gdb_index section and the new gdb-add-index shell command. Note that this feature is already present in Red Hat Enterprise Linux 6.1 and later; gdbserver now supports standard input/output (STDIO) connections, for example: (gdb) target remote | ssh myhost gdbserver - hello ; Improved behavior of the watch command using the -location parameter; Virtual method tables can be displayed by a new command, info vtbl ; Control of automatic loading of files by new commands info auto-load , set auto-load , and show auto-load ; Displaying absolute path to source file names using the set filename-display absolute command; Control flow recording with hardware support by a new command, record btrace . Notable bug fixes in GDB included in Red Hat Enterprise Linux 7 are the following: The info proc command has been updated to work on core files; Breakpoints are now set on all matching locations in all inferiors; The file name part of breakpoint location now matches trailing components of a source file name; Breakpoints can now be put on inline functions; Parameters of the template are now put in scope when the template is instantiated. In addition, Red Hat Enterprise Linux 7 provides a new package, gdb-doc , which contains the GDB Manual in PDF, HTML, and info formats. The GDB Manual was part of the main RPM package in versions of Red Hat Enterprise Linux.

Commands:
Chapter 70. ClientTls schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of ClientTls schema properties Configures TLS trusted certificates for connecting KafkaConnect, KafkaBridge, KafkaMirror, KafkaMirrorMaker2 to the cluster. 70.1. trustedCertificates Provide a list of secrets using the trustedCertificates property . 70.2. ClientTls schema properties Property Description trustedCertificates Trusted certificates for TLS connection. CertSecretSource array

Commands:
4.228. pidgin 4.228.1. RHSA-2011:1821 - Moderate: pidgin security update Updated pidgin packages that fix multiple security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Pidgin is an instant messaging program which can log in to multiple accounts on multiple instant messaging networks simultaneously. Security Fixes CVE-2011-4601 An input sanitization flaw was found in the way the AOL Open System for Communication in Realtime (OSCAR) protocol plug-in in Pidgin, used by the AOL ICQ and AIM instant messaging systems, escaped certain UTF-8 characters. A remote attacker could use this flaw to crash Pidgin via a specially-crafted OSCAR message. CVE-2011-4602 Multiple NULL pointer dereference flaws were found in the Jingle extension of the Extensible Messaging and Presence Protocol (XMPP) protocol plug-in in Pidgin. A remote attacker could use these flaws to crash Pidgin via a specially-crafted Jingle multimedia message. Red Hat would like to thank the Pidgin project for reporting these issues. Upstream acknowledges Evgeny Boger as the original reporter of CVE-2011-4601 , and Thijs Alkemade as the original reporter of CVE-2011-4602 . All Pidgin users should upgrade to these updated packages, which contain backported patches to resolve these issues. Pidgin must be restarted for this update to take effect.

Commands:
Chapter 2. FIPS support Federal Information Processing Standards (FIPS) are standards for computer security and interoperability. To use FIPS with Streams for Apache Kafka, you must have a FIPS-compliant OpenJDK (Open Java Development Kit) installed on your system. If your RHEL system is FIPS-enabled, OpenJDK automatically switches to FIPS mode when running Streams for Apache Kafka. This ensures that Streams for Apache Kafka uses the FIPS-compliant security libraries provided by OpenJDK. Minimum password length When running in the FIPS mode, SCRAM-SHA-512 passwords need to be at least 32 characters long. If you have a Kafka cluster with custom configuration that uses a password length that is less than 32 characters, you need to update your configuration. If you have any users with passwords shorter than 32 characters, you need to regenerate a password with the required length. Additional resources What are Federal Information Processing Standards (FIPS) 2.1. Installing Streams for Apache Kafka with FIPS mode enabled Enable FIPS mode before you install Streams for Apache Kafka on RHEL. Red Hat recommends installing RHEL with FIPS mode enabled, as opposed to enabling FIPS mode later. Enabling FIPS mode during the installation ensures that the system generates all keys with FIPS-approved algorithms and continuous monitoring tests in place. With RHEL running in FIPS mode, you must ensure that the Streams for Apache Kafka configuration is FIPS-compliant. Additionally, your Java implementation must also be FIPS-compliant. Note Running Streams for Apache Kafka on RHEL in FIPS mode requires a FIPS-compliant JDK. Procedure Install RHEL in FIPS mode. For further information, see the information on security hardening in the RHEL documentation . Proceed with the installation of Streams for Apache Kafka. Configure Streams for Apache Kafka to use FIPS-compliant algorithms and protocols. If used, ensure that the following configuration is compliant: SSL cipher suites and TLS versions must be supported by the JDK framework. SCRAM-SHA-512 passwords must be at least 32 characters long. Important Make sure that your installation environment and Streams for Apache Kafka configuration remains compliant as FIPS requirements change.

Commands:
Recovering a Metro-DR stretch cluster Red Hat OpenShift Data Foundation 4.9 Instructions on how to recover applications and their storage from a metro disaster in Red Hat OpenShift Data Foundation. Red Hat Storage Documentation Team Abstract This document explains how to recover from a metro disaster in Red Hat OpenShift Data Foundation. Important Recovering a Metro-DR stretch cluster is a technology preview feature. 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.

Commands:
Chapter 4. View OpenShift Data Foundation Topology The topology shows the mapped visualization of the OpenShift Data Foundation storage cluster at various abstraction levels and also lets you to interact with these layers. The view also shows how the various elements compose the Storage cluster altogether. Procedure On the OpenShift Web Console, navigate to Storage Data Foundation Topology . The view shows the storage cluster and the zones inside it. You can see the nodes depicted by circular entities within the zones, which are indicated by dotted lines. The label of each item or resource contains basic information such as status and health or indication for alerts. Choose a node to view node details on the right-hand panel. You can also access resources or deployments within a node by clicking on the search/preview decorator icon. To view deployment details Click the preview decorator on a node. A modal window appears above the node that displays all of the deployments associated with that node along with their statuses. Click the Back to main view button in the model's upper left corner to close and return to the view. Select a specific deployment to see more information about it. All relevant data is shown in the side panel. Click the Resources tab to view the pods information. This tab provides a deeper understanding of the problems and offers granularity that aids in better troubleshooting. Click the pod links to view the pod information page on OpenShift Container Platform. The link opens in a new window.

Commands:
2.8.9.2. Command Options for IPTables Rules for filtering packets are created using the iptables command. The following aspects of the packet are most often used as criteria: Packet Type - Specifies the type of packets the command filters. Packet Source/Destination - Specifies which packets the command filters based on the source or destination of the packet. Target - Specifies what action is taken on packets matching the above criteria. Refer to Section 2.8.9.2.4, "IPTables Match Options" and Section 2.8.9.2.5, "Target Options" for more information about specific options that address these aspects of a packet. The options used with specific iptables rules must be grouped logically, based on the purpose and conditions of the overall rule, for the rule to be valid. The remainder of this section explains commonly-used options for the iptables command. 2.8.9.2.1. Structure of IPTables Command Options Many iptables commands have the following structure: <table-name> - Specifies which table the rule applies to. If omitted, the filter table is used. <command> - Specifies the action to perform, such as appending or deleting a rule. <chain-name> - Specifies the chain to edit, create, or delete. <parameter>-<option> pairs - Parameters and associated options that specify how to process a packet that matches the rule. The length and complexity of an iptables command can change significantly, based on its purpose. For example, a command to remove a rule from a chain can be very short: iptables -D <chain-name> <line-number> In contrast, a command that adds a rule which filters packets from a particular subnet using a variety of specific parameters and options can be rather long. When constructing iptables commands, it is important to remember that some parameters and options require further parameters and options to construct a valid rule. This can produce a cascading effect, with the further parameters requiring yet more parameters. Until every parameter and option that requires another set of options is satisfied, the rule is not valid. Type iptables -h to view a comprehensive list of iptables command structures.

Commands:
iptables [ -t <table-name> ] <command> <chain-name> <parameter-1> <option-1> <parameter-n> <option-n>