mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. Troubleshooting RHOSO dynamic routing Diagnosing problems in a Red Hat OpenStack Services on OpenShift (RHOSO) environment that uses dynamic routing begins with examining the appropriate logs and querying the various FRRouting components with VTY shell. The topics included in this section are: OVN BGP agent and FRRouting logs Using VTY shell commands for troubleshooting BGP 8.1. OVN BGP agent and FRRouting logs The OVN BGP agent writes its logs on the Compute and Networker nodes at this location: /var/log/containers/stdouts/ovn_bgp_agent.log . The Free Range Routing (FRRouting, or FRR) components such as the BGP, BFD, and Zebra daemons write their logs on all Red Hat OpenStack Services on OpenShift (RHOSO) nodes at this location: /var/log/containers/frr/frr.log 8.2. Using VTY shell commands for troubleshooting BGP You can use the shell for Virtual Terminal Interface (VTY shell) to interact with the Free Range Routing (FRRouting, or FRR) daemons. In Red Hat OpenStack Platform, FRR daemons like bgpd run inside a container. Using the VTY shell can help you troubleshoot BGP routing issues. Prerequisites You must have sudo privileges on the host where you want to run VTY shell commands. Procedure Log in to the host where you want to troubleshoot the BGP daemon, bgpd . Typically, bgpd runs on all of the overcloud nodes. Enter the FRR container. You have two options for running VTY shell commands: Interactive mode Type sudo vtysh once to enter interactive mode to run multiple VTY shell commands. Example Direct mode Preface each VTY shell command with sudo vtysh -c . Example Here are several VTY shell BGP daemon troubleshooting commands: Tip Omit the ip argument when you are using IPv6. Display a particular routing table or all routing tables: Output routes advertised to a BGP peer Output routes received from a BGP peer Additional resources Displaying BGP Information in the FRRouting User Guide

Commands:
sudo podman exec -it frr bash
sudo vtysh > show bgp summary
sudo vtysh -c 'show bgp summary'
> show ip bgp <IPv4_address> | all > show bgp <IPv6_address> | all
> show ip bgp neighbors <router-ID> <advertised-routes>
> show ip bgp neighbors <router-ID> <received-routes>
Chapter 4. Execution environments Troubleshoot issues with execution environments. 4.1. Issue - Cannot select the "Use in Controller" option for execution environment image on private automation hub You cannot use the Use in Controller option for an execution environment image on private automation hub. You also receive the error message: "No Controllers available". To resolve this issue, connect automation controller to your private automation hub instance. Procedure Change the /etc/pulp/settings.py file on private automation hub and add one of the following parameters depending on your configuration: Single controller CONNECTED_ANSIBLE_CONTROLLERS = [' <https://my.controller.node> '] Many controllers behind a load balancer CONNECTED_ANSIBLE_CONTROLLERS = [' <https://my.controller.loadbalancer> '] Many controllers without a load balancer CONNECTED_ANSIBLE_CONTROLLERS = [' <https://my.controller.node1> ', ' <https://my.controller2.node2> '] Stop all of the private automation hub services: # systemctl stop pulpcore.service pulpcore-api.service pulpcore-content.service pulpcore-worker@1.service pulpcore-worker@2.service nginx.service redis.service Restart all of the private automation hub services: # systemctl start pulpcore.service pulpcore-api.service pulpcore-content.service pulpcore-worker@1.service pulpcore-worker@2.service nginx.service redis.service Verification Verify that you can now use the Use in Controller option in private automation hub.

Commands:
CONNECTED_ANSIBLE_CONTROLLERS = [' <https://my.controller.node> ']
CONNECTED_ANSIBLE_CONTROLLERS = [' <https://my.controller.loadbalancer> ']
CONNECTED_ANSIBLE_CONTROLLERS = [' <https://my.controller.node1> ', ' <https://my.controller2.node2> ']
systemctl stop pulpcore.service pulpcore-api.service pulpcore-content.service pulpcore-worker@1.service pulpcore-worker@2.service nginx.service redis.service
systemctl start pulpcore.service pulpcore-api.service pulpcore-content.service pulpcore-worker@1.service pulpcore-worker@2.service nginx.service redis.service
Chapter 150. KafkaNodePoolStatus schema reference Used in: KafkaNodePool Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. nodeIds integer array Node IDs used by Kafka nodes in this pool. clusterId string Kafka cluster ID. roles string (one or more of [controller, broker]) array Added in Streams for Apache Kafka 2.7. The roles currently assigned to this pool. replicas integer The current number of pods being used to provide this resource. labelSelector string Label selector for pods providing this resource.

Commands:
Chapter 2. Updating Satellite Server Update your connected Satellite Server to the patch version. You can follow this process to update the underlying operating system between minor release versions. For information to update a disconnected Satellite setup, see Chapter 3, Updating a disconnected Satellite Server . Prerequisites Back up your Satellite Server. For more information, see Backing Up Satellite Server and Capsule Server in Administering Red Hat Satellite . Warning If you customize configuration files, manually or using a tool such as Hiera, these changes are overwritten when the maintenance script runs during upgrading or updating. You can use the --noop option with the satellite-installer to test for changes. For more information, see the Red Hat Knowledgebase solution How to use the noop option to check for changes in Satellite config files during an upgrade. Procedure Ensure the Satellite Maintenance repository is enabled: On Red Hat Enterprise Linux 9: On Red Hat Enterprise Linux 8: Use the health check option to determine if the system is ready for update. On first use of this command, satellite-maintain prompts you to enter the hammer admin user credentials and saves them in the /etc/foreman-maintain/foreman-maintain-hammer.yml file. Review the results and address any highlighted error conditions before performing the update. Because of the lengthy update time, use a utility such as tmux to suspend and reattach a communication session. You can then check the update progress without staying connected to the command shell continuously. If you lose connection to the command shell where the update command is running, you can see the logged messages in the /var/log/foreman-installer/satellite.log file to check if the process completed successfully. Perform the update: Determine if the system needs a reboot: If the command told you to reboot, then reboot the system: Additional resources To restore the backup of the Satellite Server or Capsule Server, see Restoring Satellite Server or Capsule Server from a Backup

Commands:
subscription-manager repos --enable satellite-maintenance-6.16-for-rhel-9-x86_64-rpms
subscription-manager repos --enable satellite-maintenance-6.16-for-rhel-8-x86_64-rpms
satellite-maintain update check
satellite-maintain update run
dnf needs-restarting --reboothint
reboot
Chapter 90. TgzArtifact schema reference Used in: Plugin Property Description url URL of the artifact which will be downloaded. AMQ Streams 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. string sha512sum 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. string insecure 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. boolean type Must be tgz . string

Commands:
1.10. Linux Virtual Server Administration GUI This section provides an overview of the LVS configuration tool available with Red Hat Cluster Suite - the Piranha Configuration Tool . The Piranha Configuration Tool is a Web-browser graphical user interface (GUI) that provides a structured approach to creating the configuration file for LVS - /etc/sysconfig/ha/lvs.cf . To access the Piranha Configuration Tool you need the piranha-gui service running on the active LVS router. You can access the Piranha Configuration Tool locally or remotely with a Web browser. You can access it locally with this URL: http://localhost:3636 . You can access it remotely with either the hostname or the real IP address followed by :3636 . If you are accessing the Piranha Configuration Tool remotely, you need an ssh connection to the active LVS router as the root user. Starting the Piranha Configuration Tool causes the Piranha Configuration Tool welcome page to be displayed (refer to Figure 1.30, "The Welcome Panel" ). Logging in to the welcome page provides access to the four main screens or panels : CONTROL/MONITORING , GLOBAL SETTINGS , REDUNDANCY , and VIRTUAL SERVERS . In addition, the VIRTUAL SERVERS panel contains four subsections . The CONTROL/MONITORING panel is the first panel displayed after you log in at the welcome screen. Figure 1.30. The Welcome Panel The following sections provide a brief description of the Piranha Configuration Tool configuration pages. 1.10.1. CONTROL/MONITORING The CONTROL/MONITORING Panel displays runtime status. It displays the status of the pulse daemon, the LVS routing table, and the LVS-spawned nanny processes. Figure 1.31. The CONTROL/MONITORING Panel Auto update Enables the status display to be updated automatically at a user-configurable interval set in the Update frequency in seconds text box (the default value is 10 seconds). It is not recommended that you set the automatic update to an interval less than 10 seconds. Doing so may make it difficult to reconfigure the Auto update interval because the page will update too frequently. If you encounter this issue, simply click on another panel and then back on CONTROL/MONITORING . Update information now Provides manual update of the status information. CHANGE PASSWORD Clicking this button takes you to a help screen with information on how to change the administrative password for the Piranha Configuration Tool .

Commands:
8.152. php 8.152.1. RHSA-2013:1615 - Moderate: php security, bug fix, and enhancement update Updated php packages that fix three security issues, several bugs, and add one enhancement 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 scores, which give detailed severity ratings, are available for each vulnerability from the CVE links associated with each description below. PHP is an HTML-embedded scripting language commonly used with the Apache HTTP Server. Security Fixes CVE-2006-7243 It was found that PHP did not properly handle file names with a NULL character. A remote attacker could possibly use this flaw to make a PHP script access unexpected files and bypass intended file system access restrictions. CVE-2013-4248 A flaw was found in PHP's SSL client's hostname identity check when handling certificates that contain hostnames with NULL bytes. If an attacker was able to get a carefully crafted certificate signed by a trusted Certificate Authority, the attacker could use the certificate to conduct man-in-the-middle attacks to spoof SSL servers. CVE-2013-1643 It was found that the PHP SOAP parser allowed the expansion of external XML entities during SOAP message parsing. A remote attacker could possibly use this flaw to read arbitrary files that are accessible to a PHP application using a SOAP extension. Bug Fixes BZ# 892158 , BZ# 910466 Previously, when the allow_call_time_pass_reference setting was disabled, a virtual host on the Apache server could terminate with a segmentation fault when attempting to process certain PHP content. This bug has been fixed and virtual hosts no longer crash when allow_call_time_pass_reference is off. BZ# 947429 Prior to this update, if an error occurred during the operation of the fclose(), file_put_contents(), or copy() function, the function did not report it. This could have led to data loss. With this update, the aforementioned functions have been modified to properly report any errors. BZ# 969110 The internal buffer for the SQLSTATE error code can store maximum of 5 characters. Previously, when certain calls exceeded this limit, a buffer overflow occurred. With this update, messages longer than 5 characters are automatically replaced with the default "HY000" string, thus preventing the overflow. Enhancement BZ# 953814 This update adds the following rpm macros to the php package: %__php, %php_inidir, %php_incldir. Users of php are advised to upgrade to these updated packages, which fix these bugs and add this enhancement. After installing the updated packages, the httpd daemon must be restarted for the update to take effect.

Commands:
7.173. pciutils 7.173.1. RHBA-2013:0380 - pciutils bug fix and enhancement update Updated pciutils packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The pciutils packages provide various utilities for inspecting and manipulating devices connected to the Peripheral Component Interconnect (PCI) bus. Note The pciutils packages have been upgraded to upstream version 3.1.10, which provides several minor bug fixes and enhances support of PCI Express devices over the version. (BZ#826112) Users of pciutils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
8.195. scl-utils 8.195.1. RHBA-2013:1554 - scl-utils bug fix update Updated scl-utils packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The scl-utils packages provide a runtime utility and RPM packaging macros for packaging Software Collections. Software Collections allow users to concurrently install multiple versions of the same RPM packages on the system. Using the scl utility, users may enable specific versions of RPMs, which are installed into the /opt directory. Bug Fixes BZ# 949995 Previously, detection of collections that were specified to be enabled was done in the incorrect place in the code. Thus, if users wanted to enable multiple collections with a single command, only the first one was enabled, while the rest were ignored. With this update, the package scans all the arguments now, as opposed to the original approach where only the first one was taken, and all specified collections are now enabled. BZ# 955669 When starting an inspection of what collections had already been enabled, an incorrect variable was taken as a source of this information. In a specific case, when users ran a shell in an scl-enabled environment, and tried to enable an already-enabled collection, then the collection was enabled twice. This could have led to errors in a newly created environment, and, consequently, could have caused problems with applications running in this environment. This update accepts the correct variable as a source of information about the already-enabled collections, and the collections are no longer enabled multiple times. BZ# 957185 Previously, python27 required a specific byte compiler, thus, the build of python27 collection failed, because it used the incorrect byte compiler. With this update, python27 utilizes a new function to override various RPM macros and, thus, can be compiled. BZ# 957754 If the PATH variable was not set as scl-utils expected it, executing the "scl enable" command produced a "command not found" error. This was caused by the scl utility calling the scl_enabled command without an absolute path, and relying on the PATH that the user has set. This update uses an absolute path when calling the scl_enabled helper script, thus it does not rely on PATH any more, and the aforementioned errors no longer occur. BZ# 964058 Previously, when enabling collections, a check whether a collection was enabled was performed. However, independently of the result the collection was always enabled. Consequently, if a single collection had been stated multiple times on the command line, it was enabled multiple times. In the case of some destructive enable scriptlets, this might have led to unexpected behavior. This update runs the enable scriptlet only if the collection has not been enabled before, and attempts to enable a collection multiple times in one environment will be ignored. Users of scl-utils are advised to upgrade to these updated packages, which fix these bugs.

Commands:
6.4. Testing Before Upgrading the IdM Server (Recommended) It can be beneficial, and safer, to test newer versions of Identity Management before upgrading production systems. There is a relatively simple way to do this by creating a sacrificial replica and testing on that system. Set up a replica based on one of the production servers, with the same version of IdM as is running in production, as described in Chapter 4, Setting up IdM Replicas . For this example, this is called Test Replica. Make sure that Test Replica can successfully connect to the production server and domain. After verifying that Test Replica has been successfully added to the production domain, disconnect Test Replica from the network . Remove the replication agreements for Test Replica from the original IdM server and from Test Replica. Reconnect Test Replica to the network. Upgrade the packages on Test Replica using yum or whatever package update tool is appropriate for your system. For example: [root@ipareplica ~]# yum update ipa* Test common things on Test Replica, like getting Kerberos credentials, opening the server UI, and running commands.

Commands:
yum update ipa*
4.7.2. Configuring a Backup Fence Device You can define multiple fencing methods for a node. If fencing fails using the first method, the system will attempt to fence the node using the second method, followed by any additional methods you have configured. Use the following procedure to configure a backup fence device for a node. Use the procedure provided in Section 4.7.1, "Configuring a Single Fence Device for a Node" to configure the primary fencing method for a node. Beneath the display of the primary method you defined, click Add Fence Method . Enter a name for the backup fencing method that you are configuring for this node and click Submit . This displays the node-specific screen that now displays the method you have just added, below the primary fence method. Configure a fence instance for this method by clicking Add Fence Instance . This displays a drop-down menu from which you can select a fence device you have previously configured, as described in Section 4.6.1, "Creating a Fence Device" . Select a fence device for this method. If this fence device requires that you configure node-specific parameters, the display shows the parameters to configure. For information on fencing parameters, see Appendix A, Fence Device Parameters . Click Submit . This returns you to the node-specific screen with the fence method and fence instance displayed. You can continue to add fencing methods as needed. You can rearrange the order of fencing methods that will be used for this node by clicking on Move Up and Move Down .

Commands:
Chapter 82. 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. 82.1. ClientTls schema properties Property Property type Description trustedCertificates CertSecretSource array Trusted certificates for TLS connection.

Commands:
14.13.6. Configuring Virtual CPU Count To modify the number of CPUs assigned to a guest virtual machine, use the virsh setvcpus command: # virsh setvcpus {domain-name, domain-id or domain-uuid} count [[--config] [--live] | [--current] [--guest] The following parameters may be set for the virsh setvcpus command: {domain-name, domain-id or domain-uuid} - Specifies the virtual machine. count - Specifies the number of virtual CPUs to set. Note The count value cannot exceed the number of CPUs that were assigned to the guest virtual machine when it was created. It may also be limited by the host or the hypervisor. For Xen, you can only adjust the virtual CPUs of a running domain if the domain is paravirtualized. --live - The default option, used if none are specified. The configuration change takes effect on the running guest virtual machine. This is referred to as a hot plug if the number of vCPUs is increased, and hot unplug if it is reduced. Important The vCPU hot unplug feature is a Technology Preview. Therefore, it is not supported and not recommended for use in high-value deployments. --config - The configuration change takes effect on the reboot of the guest. Both the --config and --live options may be specified together if supported by the hypervisor. --current - Configuration change takes effect on the current state of the guest virtual machine. If used on a running guest, it acts as --live , if used on a shut-down guest, it acts as --config . --maximum - Sets a maximum vCPU limit that can be hot-plugged on the reboot of the guest. As such, it must only be used with the --config option, and not with the --live option. --guest - Instead of a hot plug or a hot unplug, the QEMU guest agent modifies the vCPU count directly in the running guest by enabling or disabling vCPUs. This option cannot be used with count value higher than the current number of vCPUs in the gueet, and configurations set with --guest are reset when a guest is rebooted. Example 14.4. vCPU hot plug and hot unplug To hot-plug a vCPU, run the following command on a guest with a single vCPU: This increases the number of vCPUs for guestVM1 to two. The change is performed while guestVM1 is running, as indicated by the --live option. To hot-unplug one vCPU from the same running guest, run the following: Be aware, however, that currently, using vCPU hot unplug can lead to problems with further modifications of the vCPU count.

Commands:
virsh setvcpus guestVM1 2 --live
virsh setvcpus guestVM1 1 --live