mtpti5iD/redhat-docs_dataset huggingface dataset:
4.2. Networking linuxptp The linuxptp package, included in Red Hat Enterprise Linux 6.4 as a Technology Preview, is an implementation of the Precision Time Protocol (PTP) according to IEEE standard 1588 for Linux. The dual design goals are to provide a robust implementation of the standard and to use the most relevant and modern Application Programming Interfaces (API) offered by the Linux kernel. Supporting legacy APIs and other platforms is not a goal. Package: linuxptp-0-0.6.20121114gite6bbbb PTP support in kernel drivers PTP support has been added as a technology preview to the ixgbe, igb, and tg3 kernel drivers. Packages: kernel-2.6.32-335 QFQ queuing discipline In Red Hat Enterprise Linux 6, the tc utility has been updated to work with the Quick Fair Scheduler (QFQ) kernel features. Users can now take advantage of the new QFQ traffic queuing discipline from userspace. This feature is considered a Technology Preview. Package: kernel-2.6.32-358 vios-proxy, BZ# 721119 vios-proxy is a stream-socket proxy for providing connectivity between a client on a virtual guest and a server on a Hypervisor host. Communication occurs over virtio-serial links. Package: vios-proxy-0.1-1 IPv6 support in IPVS The IPv6 support in IPVS (IP Virtual Server) is considered a Technology Preview. Package: kernel-2.6.32-358

Commands:
Chapter 1. Cluster health 1.1. Verifying OpenShift Data Foundation is healthy Storage health is visible on the Block and File and Object dashboards. Procedure In the OpenShift Web Console, click Storage Data Foundation . In the Status card of the Overview tab, click Storage System and then click the storage system link from the pop up that appears. Check if the Status card has a green tick in the Block and File and the Object tabs. Green tick indicates that the cluster is healthy. See Section 1.2, "Storage health levels and cluster state" for information about the different health states and the alerts that appear. 1.2. Storage health levels and cluster state Status information and alerts related to OpenShift Data Foundation are displayed in the storage dashboards. 1.2.1. Block and File dashboard indicators The Block and File dashboard shows the complete state of OpenShift Data Foundation and the state of persistent volumes. The states that are possible for each resource type are listed in the following table. Table 1.1. OpenShift Data Foundation health levels State Icon Description UNKNOWN OpenShift Data Foundation is not deployed or unavailable. Green Tick Cluster health is good. Warning OpenShift Data Foundation cluster is in a warning state. In internal mode, an alert is displayed along with the issue details. Alerts are not displayed for external mode. Error OpenShift Data Foundation cluster has encountered an error and some component is nonfunctional. In internal mode, an alert is displayed along with the issue details. Alerts are not displayed for external mode. 1.2.2. Object dashboard indicators The Object dashboard shows the state of the Multicloud Object Gateway and any object claims in the cluster. The states that are possible for each resource type are listed in the following table. Table 1.2. Object Service health levels State Description Green Tick Object storage is healthy. Multicloud Object Gateway is not running Shown when NooBaa system is not found. All resources are unhealthy Shown when all NooBaa pools are unhealthy. Many buckets have issues Shown when >= 50% of buckets encounter error(s). Some buckets have issues Shown when >= 30% of buckets encounter error(s). Unavailable Shown when network issues and/or errors exist. 1.2.3. Alert panel The Alert panel appears below the Status card in both the Block and File dashboard and the Object dashboard when the cluster state is not healthy. Information about specific alerts and how to respond to them is available in Troubleshooting OpenShift Data Foundation .

Commands:
Chapter 2. Multicluster storage health To view the overall storage health status across all the clusters with OpenShift Data Foundation and manage its capacity, you must first enable the multicluster dashboard on the Hub cluster. 2.1. Enabling multicluster dashboard on Hub cluster You can enable the multicluster dashboard on the install screen either before or after installing ODF Multicluster Orchestrator with the console plugin. Prerequisites Ensure that you have installed OpenShift Container Platform version 4.16 and have administrator privileges. Ensure that you have installed Multicluster Orchestrator 4.16 operator with plugin for console enabled. Ensure that you have installed Red Hat Advanced Cluster Management for Kubernetes (RHACM) 2.11 from Operator Hub. For instructions on how to install, see Installing RHACM . Ensure you have enabled observability on RHACM. See Enabling observability guidelines . Procedure Create the configmap file named observability-metrics-custom-allowlist.yaml and add the name of the custom metric to the metrics_list.yaml parameter. You can use the following YAML to list the OpenShift Data Foundation metrics on Hub cluster. For details, see Adding custom metrics . Run the following command in the open-cluster-management-observability namespace: After observability-metrics-custom-allowlist yaml is created, RHACM will start collecting the listed OpenShift Data Foundation metrics from all the managed clusters. If you want to exclude specific managed clusters from collecting the observability data, add the following cluster label to your clusters: observability: disabled . To view the multicluster health, see chapter verifying multicluster storage dashboard . 2.2. Verifying multicluster storage health on hub cluster Prerequisites Ensure that you have enabled multicluster monitoring. For instructions, see chapter Enabling multicluster dashboard . Procedure In the OpenShift web console of Hub cluster, ensure All Clusters is selected. Navigate to Data Services and click Storage System . On the Overview tab, verify that there are green ticks in front of OpenShift Data Foundation and Systems . This indicates that the operator is running and all storage systems are available. In the Status card, Click OpenShift Data Foundation to view the operator status. Click Systems to view the storage system status. The Storage system capacity card shows the following details: Name of the storage system Cluster name Graphical representation of total and used capacity in percentage Actual values for total and used capacity in TiB

Commands:
kind: ConfigMap apiVersion: v1 metadata: name: observability-metrics-custom-allowlist Namespace: open-cluster-management-observability data: metrics_list.yaml: | names: - odf_system_health_status - odf_system_map - odf_system_raw_capacity_total_bytes - odf_system_raw_capacity_used_bytes matches: - __name__="csv_succeeded",exported_namespace="openshift-storage",name=~"odf-operator.*"
oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
Chapter 5. Setting up to Measure Performance of Applications Red Hat Enterprise Linux includes several applications that can help a developer identify the causes of application performance loss. Select the Debugging Tools , Development Tools , and Performance Tools Add-ons during the system installation to install the tools OProfile , perf , and pcp . Install the tools SystemTap , which allows some types of performance analysis, and Valgrind , which includes modules for performance measurement. NOTE: Red Hat Developer Toolset is shipped as a Software Collection. The scl utility allows you to use it, running commands with the Red Hat Developer Toolset binaries used in preference to the Red Hat Enterprise Linux system equivalent. Run a SystemTap helper script for setting up the SystemTap environment. Note Running this script installs very large kernel debuginfo packages. For more frequently updated versions of SystemTap , OProfile , and Valgrind , install the Red Hat Developer Toolset package perftools . Additional Resources Red Hat Developer Toolset User Guide - Part IV., Performance Monitoring Tools

Commands:
yum install valgrind systemtap systemtap-runtime
stap-prep
yum install devtoolset-9-perftools
5.207. NetworkManager-openswan 5.207.1. RHBA-2012:0915 - NetworkManager-openswan bug fix update An updated NetworkManager-openswan package that fixes various bugs is now available for Red Hat Enterprise Linux 6. NetworkManager-openswan contains software for integrating the Openswan VPN software with NetworkManager and the GNOME desktop. Bug Fixes BZ# 696946 Prior to this update, it was possible to enter an incorrect IP address into the gateway field and it was sometimes interpreted as a gateway hostname. With this update, the code has been improved to validate IP addresses. As a result, valid IPv4 addresses, as well as hostnames, are more reliably distinguished. BZ# 748365 NetworkManager-openswan was not able to import configuration files that were previously exported using NetworkManager. This release adds support for this functionality and importing Openswan IPsec configuration files is now possible using NetworkManager. All users of NetworkManager-openswan are advised to upgrade to this updated package, which fixes these bugs.

Commands:
C.3. User Interface Plugin-related Files and Their Locations Table C.1. UI Plugin-related Files and their Locations File Location Remarks Plug-in descriptor files (meta-data) /usr/share/ovirt-engine/ui-plugins/my-plugin.json Plug-in user configuration files /etc/ovirt-engine/ui-plugins/my-plugin-config.json Plug-in resource files /usr/share/ovirt-engine/ui-plugins/<resourcePath>/PluginHostPage.html <resourcePath> is defined by the corresponding attribute in the plug-in descriptor.

Commands:
Chapter 1. About disconnected installation mirroring You can use a mirror registry to ensure that your clusters only use container images that satisfy your organizational controls on external content. Before you install a cluster on infrastructure that you provision in a restricted network, you must mirror the required container images into that environment. To mirror container images, you must have a registry for mirroring. 1.1. Creating a mirror registry If you already have a container image registry, such as Red Hat Quay, you can use it as your mirror registry. If you do not already have a registry, you can create a mirror registry using the mirror registry for Red Hat OpenShift . 1.2. Mirroring images for a disconnected installation You can use one of the following procedures to mirror your OpenShift Container Platform image repository to your mirror registry: Mirroring images for a disconnected installation Mirroring images for a disconnected installation using the oc-mirror plugin

Commands:
19.6. Displaying Guest Details You can use the Virtual Machine Monitor to view activity information for any virtual machines on your system. To view a virtual system's details: In the Virtual Machine Manager main window, highlight the virtual machine that you want to view. Figure 19.12. Selecting a virtual machine to display From the Virtual Machine Manager Edit menu, select Virtual Machine Details . When the Virtual Machine details window opens, there may be a console displayed. Should this happen, click View and then select Details . The Overview window opens first by default. To go back to this window, select Overview from the navigation pane on the left-hand side. The Overview view shows a summary of configuration details for the guest. Figure 19.13. Displaying guest details overview Select CPUs from the navigation pane on the left-hand side. The CPUs view allows you to view or change the current processor allocation. It is also possible to increase the number of virtual CPUs (vCPUs) while the virtual machine is running, which is referred to as hot plugging . Important Hot unplugging vCPUs is not supported in Red Hat Enterprise Linux 7. Figure 19.14. Processor allocation panel Select Memory from the navigation pane on the left-hand side. The Memory view allows you to view or change the current memory allocation. Figure 19.15. Displaying memory allocation Select Boot Options from the navigation pane on the left-hand side. The Boot Options view allows you to view or change the boot options including whether or not the virtual machine starts when the host boots and the boot device order for the virtual machine. Figure 19.16. Displaying boot options Each virtual disk attached to the virtual machine is displayed in the navigation pane. click a virtual disk to modify or remove it. Figure 19.17. Displaying disk configuration Each virtual network interface attached to the virtual machine is displayed in the navigation pane. click a virtual network interface to modify or remove it. Figure 19.18. Displaying network configuration

Commands:
function::ansi_set_color Name function::ansi_set_color - Set the ansi Select Graphic Rendition mode. Synopsis Arguments fg Foreground color to set. Description Sends ansi code for Select Graphic Rendition mode for the given forground color. Black (30), Blue (34), Green (32), Cyan (36), Red (31), Purple (35), Brown (33), Light Gray (37).

Commands:
ansi_set_color(fg:long)
Chapter 145. KafkaNodePoolSpec schema reference Used in: KafkaNodePool Property Description replicas The number of pods in the pool. integer storage Storage configuration (disk). Cannot be updated. The type depends on the value of the storage.type property within the given object, which must be one of [ephemeral, persistent-claim, jbod]. EphemeralStorage , PersistentClaimStorage , JbodStorage roles The roles that the nodes in this pool will have when KRaft mode is enabled. Supported values are 'broker' and 'controller'. This field is required. When KRaft mode is disabled, the only allowed value if broker . string (one or more of [controller, broker]) array resources CPU and memory resources to reserve. For more information, see the external documentation for core/v1 resourcerequirements . ResourceRequirements jvmOptions JVM Options for pods. JvmOptions template Template for pool resources. The template allows users to specify how the resources belonging to this pool are generated. KafkaNodePoolTemplate

Commands:
14.8. Additional Resources dhcpd(8) man page - Describes how the DHCP daemon works. dhcpd.conf(5) man page - Explains how to configure the DHCP configuration file; includes some examples. dhcpd.leases(5) man page - Describes a persistent database of leases. dhcp-options(5) man page - Explains the syntax for declaring DHCP options in dhcpd.conf ; includes some examples. dhcrelay(8) man page - Explains the DHCP Relay Agent and its configuration options. /usr/share/doc/dhcp- version / - Contains example files, README files, and release notes for current versions of the DHCP service.

Commands:
Chapter 25. Pricing This section describes different ways you can charge your developers for using your API. Setup fee is a one-time charge applied upon subscription to the service, it is not charged when switching to another plan. It appears in the invoice/credit card only on the first month of a subscription. Can be configured on application plans, service plans, and account plans. Cost per month is a recurring cost charged monthly. It is prorated if the subscription occurred in the middle of the month. Sometimes it is referred to as fixed fee . Can be configured on application plans, service plans, and account plans. Variable costs are the costs derived from the pricing rules applied to each method/metric configured in the application plan. They are based on the usage of your API and therefore cannot be known in advance, only when the billing period has concluded. Only available on application plans. Example 25.1. Pricing rules Pricing rules define the cost of each API request. Multiple pricing rules on the same metric divide up the ranges of when a pricing rule applies. Pricing rules are based on calendar month, and the counter is reset at 00:00 UTC of the 1st day of each month. Example 1 Example 2 Example 3 Note Pricing rules are defined for metrics and methods. The actual API requests are mapped to these metrics and methods through the Mapping Rules. 25.2. Setting pricing rules Go to [Your_API_service] > Applications > Application Plans . Select an existing application plan or create a new one. In the section Metrics, Methods, Limits & Pricing Rules click Pricing (x) to open the pricing section. Click new pricing rule. Set the values From, To and Cost per Unit and click Create pricing rule . Repeat the last two steps to create all the necessary pricing rules ranges. Leave the To field empty to set the rule to to infinity . The maximum number of decimals is set to 4 for the cost of metric, if a number is added with more decimals, the value is rounded to a number with 4 decimal places. 25.3. Update existing pricing rules Click on edit. Make the necessary adjustments to the From, To and Cost per Unit fields. Click Update pricing rule.

Commands:
If you have a plan with monthly cost of USD10, but want to charge your developer a USD5 setup fee. The initial charge would be for USD15, while all subsequent charges would be for USD10.
Until 100 calls per month (from 1 to 100) each API call can be charged at USD0.04, and starting from the call 101 (from 101 to infinity) the calls are charged at USD0.10.
The first 1000 calls are not charged (cost USD0), because they are included in the plan which has a monthly fixed cost. Starting from call 1001, each call is charged at USD0.50.
Calls from 1 to 100 are charged at USD0.30, 100 to 500 - at USD0.40, and 500 and further - at USD0.50.
Chapter 2. Security Tips for Installation Security begins with the first time you put that CD or DVD into your disk drive to install Red Hat Enterprise Linux 7. Configuring your system securely from the beginning makes it easier to implement additional security settings later. 2.1. Securing BIOS Password protection for the BIOS (or BIOS equivalent) and the boot loader can prevent unauthorized users who have physical access to systems from booting using removable media or obtaining root privileges through single user mode. The security measures you should take to protect against such attacks depends both on the sensitivity of the information on the workstation and the location of the machine. For example, if a machine is used in a trade show and contains no sensitive information, then it may not be critical to prevent such attacks. However, if an employee's laptop with private, unencrypted SSH keys for the corporate network is left unattended at that same trade show, it could lead to a major security breach with ramifications for the entire company. If the workstation is located in a place where only authorized or trusted people have access, however, then securing the BIOS or the boot loader may not be necessary. 2.1.1. BIOS Passwords The two primary reasons for password protecting the BIOS of a computer are [1] : Preventing Changes to BIOS Settings - If an intruder has access to the BIOS, they can set it to boot from a CD-ROM or a flash drive. This makes it possible for them to enter rescue mode or single user mode, which in turn allows them to start arbitrary processes on the system or copy sensitive data. Preventing System Booting - Some BIOSes allow password protection of the boot process. When activated, an attacker is forced to enter a password before the BIOS launches the boot loader. Because the methods for setting a BIOS password vary between computer manufacturers, consult the computer's manual for specific instructions. If you forget the BIOS password, it can either be reset with jumpers on the motherboard or by disconnecting the CMOS battery. For this reason, it is good practice to lock the computer case if possible. However, consult the manual for the computer or motherboard before attempting to disconnect the CMOS battery. 2.1.1.1. Securing Non-BIOS-based Systems Other systems and architectures use different programs to perform low-level tasks roughly equivalent to those of the BIOS on x86 systems. For example, the Unified Extensible Firmware Interface ( UEFI ) shell. For instructions on password protecting BIOS-like programs, see the manufacturer's instructions. [1] Since system BIOSes differ between manufacturers, some may not support password protection of either type, while others may support one type but not the other.

Commands:
2.3. Attaching Subsystems to, and Detaching Them from, an Existing Hierarchy To add a subsystem to an existing hierarchy, detach it from an existing hierarchy, or move it to a different hierarchy, edit the mount section of the /etc/cgconfig.conf file as root, using the same syntax described in Section 2.2, "Creating a Hierarchy and Attaching Subsystems" . When cgconfig starts, it will reorganize the subsystems according to the hierarchies that you specify. Alternative method To add an unattached subsystem to an existing hierarchy, remount the hierarchy. Include the extra subsystem in the mount command, together with the remount option. Example 2.4. Remounting a hierarchy to add a subsystem The lssubsys command shows cpu , cpuset , and memory subsystems attached to the cpu_and_mem hierarchy: Remount the cpu_and_mem hierarchy, using the remount option, and include cpuacct in the list of subsystems: The lssubsys command now shows cpuacct attached to the cpu_and_mem hierarchy: Analogously, you can detach a subsystem from an existing hierarchy by remounting the hierarchy and omitting the subsystem name from the -o options. For example, to then detach the cpuacct subsystem, simply remount and omit it:

Commands:
~]# lssubsys -am cpu,cpuset,memory /cgroup/cpu_and_mem net_cls ns cpuacct devices freezer blkio
~]# mount -t cgroup -o remount,cpu,cpuset,cpuacct,memory cpu_and_mem /cgroup/cpu_and_mem
~]# lssubsys -am cpu,cpuacct,cpuset,memory /cgroup/cpu_and_mem net_cls ns devices freezer blkio
~]# mount -t cgroup -o remount,cpu,cpuset,memory cpu_and_mem /cgroup/cpu_and_mem
Chapter 1. Introduction to Service Telemetry Framework release This release of Service Telemetry Framework (STF) provides new features and resolved issues specific to STF. STF uses components from other Red Hat products. For specific information pertaining to the support of these components, see https://access.redhat.com/site/support/policy/updates/openstack/platform/ and https://access.redhat.com/support/policy/updates/openshift/ . STF 1.5 is compatible with OpenShift Container Platform version 4.14 and 4.16 as the deployment platform. 1.1. Product support The Red Hat Customer Portal offers resources to guide you through the installation and configuration of Service Telemetry Framework. The following types of documentation are available through the Customer Portal: Product documentation Knowledge base articles and solutions Technical briefs Support case management You can access the Customer Portal at https://access.redhat.com/ .

Commands: