mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Known issues This section documents known issues found in this release of Red Hat Ceph Storage. 6.1. The Cephadm utility Some NFS daemons may not produce logs Currently, in a cephadm-deployed NFS service with multiple NFS daemons, only one would be serving IO, causing the user to come across NFS daemons that produce no logs. There is no workaround for this as of now. Bugzilla:2251653 Prevent Mutex from failing when unlocking. Previously, when a Mutex that was not locked was attempted to be unlocked, the Mutex crashed. As a workaround, verify if the Mutex is locked in the first place before unlocking. Bugzilla:2216442 ceph orch ps command does not display a version for monitoring stack daemons In cephadm , due to the version grabbing code currently being incompatible with the downstream monitoring stack containers, version grabbing fails for monitoring stack daemons, such as node-exporter , prometheus , and alertmanager . Encryption of multipart uploads requires special handling around the part boundaries because each part is uploaded and encrypted separately. In multi-site, objects are encrypted, and multipart uploads are replicated as a single part. As a result, the replicated copy loses its knowledge about the original part boundaries required to decrypt the data correctly, which causes this corruption. As a workaround, if the user needs to find the version, the daemons' container names include the version. Bugzilla:2125382 6.2. Ceph Dashboard Ceph Object Gateway page does not load after a multi-site configuration The Ceph Object Gateway page does not load because the dashboard cannot find the correct access key and secret key for the new realm during multi-site configuration. As a workaround, use the ceph dashboard set-rgw-credentials command to manually update the keys. Bugzilla:2231072 6.3. Ceph Object Gateway JSON select count( ) from S3Object[ ]; queries are lagging and cause high CPU usage When running the select count( ) from S3Object[ ]; query, the time lapse and radosgw CPU utilization are very high compared to CSV object queries. As a workaround, when running the JSON query, use count() instead of count(*) query. Bugzilla:2240974 s3select and Trino fail when processing JSON object using s3select When Trino processes a JSON object using the s3select request, the request fails causing Trino to fail too. This emits the wrong json dataType should use DOCUMENT error message in the Ceph Object Gateway logs. As a workaround, it is sometimes possible to use the s3select request directly, not using Trino. Bugzilla:249756

Commands:
5.319. sysstat 5.319.1. RHBA-2012:0866 - sysstat bug fix and enhancement update An updated sysstat package that fixes multiple bugs and adds three enhancements is now available for Red Hat Enterprise Linux 6. The sysstat package contains a set of utilities which enable system monitoring of disks, network, and other I/O activity. Bug Fixes BZ# 690562 Prior to this update, the cifsiostat utility did not report the correct number of open files on CIFS file systems. A patch has been applied to ensure that the cifsiostat utility outputs the correct number of open files on CIFS file systems. BZ# 694759 Prior to this update, the "iostat -n" command did not list NFS shares with excessively long names. The underlying source code has been revised to ensure that the command lists all NFS shares available. BZ# 771594 Previously, nr_requests could overflow if set to high values. As a consequence, the "iostat" and "sar -d" command would report the overflowed values from the /proc/diskstats file instead of the proper values. The underlying source code has been modified to ensure that the "iostat" and "sar -d" commands output the correct information. BZ# 801453 Previously, the sa2 script could return an error code even when the script completed successfully. The underlying source code has been modified so that the sa2 script now returns the correct code on successful completion. BZ# 801702 Running the "sar" command with the "-p" option to "pretty-print" device names did not work as expected if the device minor number was greater than 256. The device names were incorrectly displayed as "nodev" or "dev-[major number]-[minor number]". With this update, the value of the IOC_MAXNIMOR constant has been increased, and devices with the minor number greater than 256 are now displayed correctly in the "sar" output. Enhancements BZ# 674648 Previously, on 64-bit PowerPC architectures, the mpstat utility displayed all processors, including both busy and idle processors with zero activity. This update introduces a new option for the mpstat utility, "-P ON". If this option is used, mpstat lists only online processors. BZ# 693398 With this update, the SADC_OPTIONS configuration variable has been moved from the sysstat init script, located in the /etc/init.d/ directory, to the sysstat configuration file located in the /etc/sysconfig/ directory. Also, a note about the -S option was added to the sadc manual page. BZ# 766431 Previously, the iostat utility did not display target device information if a symbolic link was specified as an input parameter. This update adds support for symbolic links as input parameters in the iostat utility. All users of sysstat are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
3.6. freezer The freezer subsystem suspends or resumes tasks in a cgroup. freezer.state freezer.state is only available in non-root cgroups and has three possible values: FROZEN - tasks in the cgroup are suspended. FREEZING - the system is in the process of suspending tasks in the cgroup. THAWED - tasks in the cgroup have resumed. To suspend a specific process: Move that process to a cgroup in a hierarchy which has the freezer subsystem attached to it. Freeze that particular cgroup to suspend the process contained in it. It is not possible to move a process into a suspended (frozen) cgroup. Note that while the FROZEN and THAWED values can be written to freezer.state , FREEZING cannot be written, only read.

Commands:
1.3. Indirect Integration The main advantage of the indirect integration is to manage Linux systems and policies related to those systems centrally while enabling users from Active Directory (AD) domains to transparently access Linux systems and services. There are two different approaches to the indirect integration: Trust-based solution The recommended approach is to leverage Identity Management (IdM) in Red Hat Enterprise Linux as the central server to control Linux systems and then establish cross-realm Kerberos trust with AD, enabling users from AD to log on to and to use single sign-on to access Linux systems and resources. This solution uses the Kerberos capability to establish trusts between different identity sources. IdM presents itself to AD as a separate forest and takes advantage of the forest-level trusts supported by AD. In complex environments, a single IdM forest can be connected to multiple AD forests. This setup enables better separation of duties for different functions in the organization. AD administrators can focus on users and policies related to users while Linux administrators have full control over the Linux infrastructure. In such a case, the Linux realm controlled by IdM is analogous to an AD resource domain or realm but with Linux systems in it. Note In Windows, every domain is a Kerberos realm and a DNS domain at the same time. Every domain managed by the domain controller needs to have its own dedicated DNS zone. The same applies when IdM is trusted by AD as a forest. AD expects IdM to have its own DNS domain. For the trust setup to work, the DNS domain needs to be dedicated to the Linux environment. Note that in trust environments, IdM enables you to use ID views to configure POSIX attributes for AD users on the IdM server. For details, see: Chapter 8, Using ID Views in Active Directory Environments SSSD Client-side Views in the System-Level Authentication Guide Synchronization-based solution An alternative to a trust-based solution is to leverage user synchronization capability, also available in IdM or Red Hat Directory Server (RHDS), allowing user accounts (and with RHDS also group accounts) to be synchronized from AD to IdM or RHDS, but not in the opposite direction. User synchronization has certain limitations, including: duplication of users the need to synchronize passwords, which requires a special component on all domain controllers in an AD domain to be able to capture passwords, all users must first manually change them synchronization supports only a single domain only one domain controller in AD can be used to synchronize data to one instance of IdM or RHDS In some integration scenarios, the user synchronization may be the only available option, but in general, use of the synchronization approach is discouraged in favor of the cross-realm trust-based integration.

Commands:
Chapter 1. Introduction 1.1. About the MTA extension for Microsoft Visual Studio Code You can migrate and modernize applications by using the Migration Toolkit for Applications (MTA) extension for Microsoft Visual Studio Code. The MTA extension analyzes your projects using customizable rulesets, marks issues in the source code, provides guidance to fix the issues, and offers automatic code replacement, if possible. The MTA extension is also compatible with Visual Studio Codespaces, the Microsoft cloud-hosted development environment. 1.2. About the Migration Toolkit for Applications What is the Migration Toolkit for Applications? Migration Toolkit for Applications (MTA) accelerates large-scale application modernization efforts across hybrid cloud environments on Red Hat OpenShift. This solution provides insight throughout the adoption process, at both the portfolio and application levels: inventory, assess, analyze, and manage applications for faster migration to OpenShift via the user interface. In MTA 7.1 and later, when you add an application to the Application Inventory , MTA automatically creates and executes language and technology discovery tasks. Language discovery identifies the programming languages used in the application. Technology discovery identifies technologies, such as Enterprise Java Beans (EJB), Spring, etc. Then, each task assigns appropriate tags to the application, reducing the time and effort you spend manually tagging the application. MTA uses an extensive default questionnaire as the basis for assessing your applications, or you can create your own custom questionnaire, enabling you to estimate the difficulty, time, and other resources needed to prepare an application for containerization. You can use the results of an assessment as the basis for discussions between stakeholders to determine which applications are good candidates for containerization, which require significant work first, and which are not suitable for containerization. MTA analyzes applications by applying one or more rulesets to each application considered to determine which specific lines of that application must be modified before it can be modernized. MTA examines application artifacts, including project source directories and application archives, and then produces an HTML report highlighting areas needing changes. How does the Migration Toolkit for Applications simplify migration? The Migration Toolkit for Applications looks for common resources and known trouble spots when migrating applications. It provides a high-level view of the technologies used by the application. MTA generates a detailed report evaluating a migration or modernization path. This report can help you to estimate the effort required for large-scale projects and to reduce the work involved.

Commands:
1.10.4.2. REAL SERVER Subsection Clicking on the REAL SERVER subsection link at the top of the panel displays the EDIT REAL SERVER subsection. It displays the status of the physical server hosts for a particular virtual service. Figure 1.36. The REAL SERVER Subsection Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Figure 1.37, "The REAL SERVER Configuration Panel" . Figure 1.37. The REAL SERVER Configuration Panel This panel consists of three entry fields: Name A descriptive name for the real server. Note This name is not the hostname for the machine, so make it descriptive and easily identifiable. Address The real server's IP address. Since the listening port is already specified for the associated virtual server, do not add a port number. Weight An integer value indicating this host's capacity relative to that of other hosts in the pool. The value can be arbitrary, but treat it as a ratio in relation to other real servers.

Commands:
4.64. firstaidkit 4.64.1. RHBA-2011:1709 - firstaidkit bug fix update Updated firstaidkit packages that fix two bugs are now available for Red Hat Enterprise Linux 6. FirstAidKit is a tool that runs automated diagnostics of an installed system. Bug Fixes BZ# 664876 Previously, FirstAidKit's GRUB plug-in incorrectly reported failure if GRUB was installed into the Master Boot Record (MBR). Due to the plug-in being unreliable, it has been removed from the firstaidkit package. BZ# 738563 The firstaidkit-plugin-grub package has been removed from Red Hat Enterprise Linux 6.2. As a consequence, in rare cases, the system upgrade operation may fail with unresolved dependencies if the plug-in has been installed in a version of Red Hat Enterprise Linux. To avoid this problem, the firstaidkit-plugin-grub package should be removed before upgrading the system. However, in most cases, the system upgrade completes as expected. All users of firstaidkit are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 1. Monitoring APIs 1.1. Alertmanager [monitoring.coreos.com/v1] Description Alertmanager describes an Alertmanager cluster. Type object 1.2. AlertmanagerConfig [monitoring.coreos.com/v1beta1] Description AlertmanagerConfig defines a namespaced AlertmanagerConfig to be aggregated across multiple namespaces configuring one Alertmanager cluster. Type object 1.3. AlertRelabelConfig [monitoring.openshift.io/v1] Description AlertRelabelConfig defines a set of relabel configs for alerts. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.4. AlertingRule [monitoring.openshift.io/v1] Description AlertingRule represents a set of user-defined Prometheus rule groups containing alerting rules. This resource is the supported method for cluster admins to create alerts based on metrics recorded by the platform monitoring stack in OpenShift, i.e. the Prometheus instance deployed to the openshift-monitoring namespace. You might use this to create custom alerting rules not shipped with OpenShift based on metrics from components such as the node_exporter, which provides machine-level metrics such as CPU usage, or kube-state-metrics, which provides metrics on Kubernetes usage. The API is mostly compatible with the upstream PrometheusRule type from the prometheus-operator. The primary difference being that recording rules are not allowed here - only alerting rules. For each AlertingRule resource created, a corresponding PrometheusRule will be created in the openshift-monitoring namespace. OpenShift requires admins to use the AlertingRule resource rather than the upstream type in order to allow better OpenShift specific defaulting and validation, while not modifying the upstream APIs directly. You can find upstream API documentation for PrometheusRule resources here: https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.5. PodMonitor [monitoring.coreos.com/v1] Description PodMonitor defines monitoring for a set of pods. Type object 1.6. Probe [monitoring.coreos.com/v1] Description Probe defines monitoring for a set of static targets or ingresses. Type object 1.7. Prometheus [monitoring.coreos.com/v1] Description Prometheus defines a Prometheus deployment. Type object 1.8. PrometheusRule [monitoring.coreos.com/v1] Description PrometheusRule defines recording and alerting rules for a Prometheus instance Type object 1.9. ServiceMonitor [monitoring.coreos.com/v1] Description ServiceMonitor defines monitoring for a set of services. Type object 1.10. ThanosRuler [monitoring.coreos.com/v1] Description ThanosRuler defines a ThanosRuler deployment. Type object

Commands:
Chapter 4. Deploying and updating an overcloud with containers This chapter provides info on how to create a container-based overcloud and keep it updated. 4.1. Deploying an overcloud This procedure demonstrates how to deploy an overcloud with minimum configuration. The result will be a basic two-node overcloud (1 Controller node, 1 Compute node). Procedure Source the stackrc file: Run the deploy command and include the file containing your overcloud image locations (usually overcloud_images.yaml ): Wait until the overcloud completes deployment. 4.2. Updating an overcloud For information on updating a containerized overcloud, see the Keeping Red Hat OpenStack Platform Updated guide.

Commands:
source ~/stackrc
(undercloud) USD openstack overcloud deploy --templates -e /home/stack/templates/overcloud_images.yaml --ntp-server pool.ntp.org
B.2.7. Verifying Verifying a package compares information about files installed from a package with the same information from the original package. Among other things, verifying compares the file size, MD5 sum, permissions, type, owner, and group of each file. The command rpm -V verifies a package. You can use any of the Verify Options listed for querying to specify the packages you want to verify. A simple use of verifying is rpm -V tree , which verifies that all the files in the tree package are as they were when they were originally installed. For example: To verify a package containing a particular file: In this example, /usr/bin/tree is the absolute path to the file used to query a package. To verify ALL installed packages throughout the system (which will take some time): To verify an installed package against an RPM package file: This command can be useful if you suspect that your RPM database is corrupt. If everything verified properly, there is no output. If there are any discrepancies, they are displayed. The format of the output is a string of eight characters (a " c " denotes a configuration file) and then the file name. Each of the eight characters denotes the result of a comparison of one attribute of the file to the value of that attribute recorded in the RPM database. A single period ( . ) means the test passed. The following characters denote specific discrepancies: 5 - MD5 checksum S - file size L - symbolic link T - file modification time D - device U - user G - group M - mode (includes permissions and file type) ? - unreadable file (file permission errors, for example) If you see any output, use your best judgment to determine if you should remove the package, reinstall it, or fix the problem in another way.

Commands:
-Vf /usr/bin/tree
-Va
-Vp tree-1.5.3-2.el6.x86_64.rpm
10.2.2.2. Logging The following logging directives have been removed: AgentLog RefererLog RefererIgnore However, agent and referrer logs are still available using the CustomLog and LogFormat directives. For more on this topic, refer to the following documentation on the Apache Software Foundation's website: http://httpd.apache.org/docs-2.0/mod/mod_log_config.html#customlog http://httpd.apache.org/docs-2.0/mod/mod_log_config.html#logformat

Commands:
Chapter 55. BrokerCapacity schema reference Used in: CruiseControlSpec Property Description disk The disk property has been deprecated. The Cruise Control disk capacity setting has been deprecated, is ignored, and will be removed in the future Broker capacity for disk in bytes. Use a number value with either standard OpenShift byte units (K, M, G, or T), their bibyte (power of two) equivalents (Ki, Mi, Gi, or Ti), or a byte value with or without E notation. For example, 100000M, 100000Mi, 104857600000, or 1e+11. string cpuUtilization The cpuUtilization property has been deprecated. The Cruise Control CPU capacity setting has been deprecated, is ignored, and will be removed in the future Broker capacity for CPU resource utilization as a percentage (0 - 100). integer cpu Broker capacity for CPU resource in cores or millicores. For example, 1, 1.500, 1500m. For more information on valid CPU resource units see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu . string inboundNetwork Broker capacity for inbound network throughput in bytes per second. Use an integer value with standard OpenShift byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s. string outboundNetwork Broker capacity for outbound network throughput in bytes per second. Use an integer value with standard OpenShift byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s. string overrides Overrides for individual brokers. The overrides property lets you specify a different capacity configuration for different brokers. BrokerCapacityOverride array

Commands:
25.13. iSCSI Discovery Configuration The default iSCSI configuration file is /etc/iscsi/iscsid.conf . This file contains iSCSI settings used by iscsid and iscsiadm . During target discovery, the iscsiadm tool uses the settings in /etc/iscsi/iscsid.conf to create two types of records: Node records in /var/lib/iscsi/nodes When logging into a target, iscsiadm uses the settings in this file. Discovery records in /var/lib/iscsi/ discovery_type When performing discovery to the same destination, iscsiadm uses the settings in this file. Before using different settings for discovery, delete the current discovery records (i.e. /var/lib/iscsi/ discovery_type ) first. To do this, use the following command: [5] Here, discovery_type can be either sendtargets , isns , or fw . For details on different types of discovery, refer to the DISCOVERY TYPES section of the iscsiadm (8) man page. There are two ways to reconfigure discovery record settings: Edit the /etc/iscsi/iscsid.conf file directly prior to performing a discovery. Discovery settings use the prefix discovery ; to view them, run: Alternatively, iscsiadm can also be used to directly change discovery record settings, as in: Refer to the iscsiadm (8) man page for more information on available setting options and valid value options for each. After configuring discovery settings, any subsequent attempts to discover new targets will use the new settings. Refer to Section 25.15, "Scanning iSCSI Interconnects" for details on how to scan for new iSCSI targets. For more information on configuring iSCSI target discovery, refer to the man pages of iscsiadm and iscsid . The /etc/iscsi/iscsid.conf file also contains examples on proper configuration syntax. [5] The target_IP and port variables refer to the IP address and port combination of a target/portal, respectively. For more information, refer to Section 25.7.1, "iSCSI API" and Section 25.15, "Scanning iSCSI Interconnects" .

Commands:
iscsiadm -m discovery -t discovery_type -p target_IP : port -o delete
iscsiadm -m discovery -t discovery_type -p target_IP : port
iscsiadm -m discovery -t discovery_type -p target_IP : port -o update -n setting -v % value