mtpti5iD/redhat-docs_dataset huggingface dataset:
3.10. Searching for Hosts The following table describes all search options for hosts. Table 3.6. Searching for Hosts Property (of resource or resource-type) Type Description (Reference) Vms. Vms-prop Depends on property type The property of the virtual machines associated with the host. Templates. templates-prop Depends on property type The property of the templates associated with the host. Events. events-prop Depends on property type The property of the events associated with the host. Users. users-prop Depends on property type The property of the users associated with the host. name String The name of the host. status List The availability of the host. external_status String The health status of the host as reported by external systems and plug-ins. cluster String The cluster to which the host belongs. address String The unique name that identifies the host on the network. cpu_usage Integer The percent of processing power used. mem_usage Integer The percentage of memory used. network_usage Integer The percentage of network usage. load Integer Jobs waiting to be executed in the run-queue per processor, in a given time slice. version Integer The version number of the operating system. cpus Integer The number of CPUs on the host. memory Integer The amount of memory available. cpu_speed Integer The processing speed of the CPU. cpu_model String The type of CPU. active_vms Integer The number of virtual machines currently running. migrating_vms Integer The number of virtual machines currently being migrated. committed_mem Integer The percentage of committed memory. tag String The tag assigned to the host. type String The type of host. datacenter String The data center to which the host belongs. sortby List Sorts the returned results by one of the resource properties. page Integer The page number of results to display. Example Hosts: cluster = Default and Vms.os = rhel6 This example returns a list of hosts which are part of the Default cluster and host virtual machines running the Red Hat Enterprise Linux 6 operating system.

Commands:
E.10. Additional Resources This chapter is only intended as an introduction to GRUB. Consult the following resources to discover more about how GRUB works. E.10.1. Installed Documentation /usr/share/doc/grub- <version-number> / - This directory contains good information about using and configuring GRUB, where <version-number> corresponds to the version of the GRUB package installed. info grub - The GRUB info page contains a tutorial, a user reference manual, a programmer reference manual, and a FAQ document about GRUB and its usage.

Commands:
8.250. unixODBC 8.250.1. RHBA-2014:0869 - unixODBC bug fix update Updated unixODBC packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The unixODBC packages contain a framework that supports accessing databases through the ODBC protocol. Bug Fixes BZ# 768986 Prior to this update, the desktop file for unixODBC, ODBCConfig.desktop, contained deprecated options and incorrect values. Consequently, the unixODBC application was not appropriately categorized. In this update, the options and values have been fixed and the application categorization works as intended. BZ# 1060225 Previously, file name values were hard-coded in the ODBC Driver Manager. As a consequence, the Driver Manager did not correctly interact with other applications after an update. The current update changes the hard-coded values to dynamically determined ones, and updating no longer causes Driver Manager incompatibilities with other applications. Users of unixODBC are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 18. Using the mount Command On Linux, UNIX, and similar operating systems, file systems on different partitions and removable devices (CDs, DVDs, or USB flash drives for example) can be attached to a certain point (the mount point ) in the directory tree, and then detached again. To attach or detach a file system, use the mount or umount command respectively. This chapter describes the basic use of these commands, as well as some advanced topics, such as moving a mount point or creating shared subtrees. 18.1. Listing Currently Mounted File Systems To display all currently attached file systems, run the mount command with no additional arguments: This command displays the list of known mount points. Each line provides important information about the device name, the file system type, the directory in which it is mounted, and relevant mount options in the following form: device on directory type type ( options ) The findmnt utility, which allows users to list mounted file systems in a tree-like form, is also available from Red Hat Enterprise Linux 6.1. To display all currently attached file systems, run the findmnt command with no additional arguments: 18.1.1. Specifying the File System Type By default, the output of the mount command includes various virtual file systems such as sysfs and tmpfs . To display only the devices with a certain file system type, supply the -t option on the command line: Similarly, to display only the devices with a certain file system type by using the findmnt command, type: For a list of common file system types, refer to Table 18.1, "Common File System Types" . For an example usage, see Example 18.1, "Listing Currently Mounted ext4 File Systems" . Example 18.1. Listing Currently Mounted ext4 File Systems Usually, both / and /boot partitions are formatted to use ext4 . To display only the mount points that use this file system, type the following at a shell prompt: To list such mount points using the findmnt command, type:

Commands:
mount
findmnt
mount -t type
findmnt -t type
~]USD mount -t ext4 /dev/sda2 on / type ext4 (rw) /dev/sda1 on /boot type ext4 (rw)
~]USD findmnt -t ext4 TARGET SOURCE FSTYPE OPTIONS / /dev/sda2 ext4 rw,realtime,seclabel,barrier=1,data=ordered /boot /dev/sda1 ext4 rw,realtime,seclabel,barrier=1,data=ordered
Chapter 3. Enabling Linux control group version 1 (cgroup v1) As of OpenShift Container Platform 4.14, OpenShift Container Platform uses Linux control group version 2 (cgroup v2) in your cluster. If you are using cgroup v1 on OpenShift Container Platform 4.13 or earlier, migrating to OpenShift Container Platform 4.17 will not automatically update your cgroup configuration to version 2. A fresh installation of OpenShift Container Platform 4.14 or later will use cgroup v2 by default. However, you can enable Linux control group version 1 (cgroup v1) upon installation. Enabling cgroup v1 in OpenShift Container Platform disables all cgroup v2 controllers and hierarchies in your cluster. Important cgroup v1 is a deprecated feature. Deprecated functionality is still included in OpenShift Container Platform and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. For the most recent list of major functionality that has been deprecated or removed within OpenShift Container Platform, refer to the Deprecated and removed features section of the OpenShift Container Platform release notes. cgroup v2 is the current version of the Linux cgroup API. cgroup v2 offers several improvements over cgroup v1, including a unified hierarchy, safer sub-tree delegation, new features such as Pressure Stall Information , and enhanced resource management and isolation. However, cgroup v2 has different CPU, memory, and I/O management characteristics than cgroup v1. Therefore, some workloads might experience slight differences in memory or CPU usage on clusters that run cgroup v2. You can switch between cgroup v1 and cgroup v2, as needed, by editing the node.config object. For more information, see "Configuring the Linux cgroup on your nodes" in the "Additional resources" of this section. 3.1. Enabling Linux cgroup v1 during installation You can enable Linux control group version 1 (cgroup v1) when you install a cluster by creating installation manifests. Important cgroup v1 is a deprecated feature. Deprecated functionality is still included in OpenShift Container Platform and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. For the most recent list of major functionality that has been deprecated or removed within OpenShift Container Platform, refer to the Deprecated and removed features section of the OpenShift Container Platform release notes. Procedure Create or edit the node.config object to specify the v1 cgroup: apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2" Proceed with the installation as usual. Additional resources OpenShift Container Platform installation overview Configuring the Linux cgroup on your nodes

Commands:
apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2"
Installation overview OpenShift Container Platform 4.15 Overview content for installing OpenShift Container Platform Red Hat OpenShift Documentation Team

Commands:
oc get nodes
NAME STATUS ROLES AGE VERSION example-compute1.example.com Ready worker 13m v1.21.6+bb8d50a example-compute2.example.com Ready worker 13m v1.21.6+bb8d50a example-compute4.example.com Ready worker 14m v1.21.6+bb8d50a example-control1.example.com Ready master 52m v1.21.6+bb8d50a example-control2.example.com Ready master 55m v1.21.6+bb8d50a example-control3.example.com Ready master 55m v1.21.6+bb8d50a
oc get machines -A
NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
capabilities: baselineCapabilitySet: v4.11 1 additionalEnabledCapabilities: 2 - CSISnapshot - Console - Storage
oc get clusterversion version -o jsonpath='{.spec.capabilities}{"\n"}{.status.capabilities}{"\n"}'
{"additionalEnabledCapabilities":["openshift-samples"],"baselineCapabilitySet":"None"} {"enabledCapabilities":["openshift-samples"],"knownCapabilities":["CSISnapshot","Console","Insights","Storage","baremetal","marketplace","openshift-samples"]}
oc patch clusterversion version --type merge -p '{"spec":{"capabilities":{"baselineCapabilitySet":"vCurrent"}}}' 1
oc get clusterversion version -o jsonpath='{.spec.capabilities.additionalEnabledCapabilities}{"\n"}'
openshift-samples
oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["openshift-samples", "marketplace"]}}}'
oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="ImplicitlyEnabledCapabilities")]}{"\n"}'
lastTransitionTime: 2022-07-22T03:14:35Z
message: The following capabilities could not be disabled: openshift-samples
reason: CapabilitiesImplicitlyEnabled
status: True
type: ImplicitlyEnabledCapabilities
function::task_state Name function::task_state - The state of the task. Synopsis Arguments task task_struct pointer. General Syntax task_state:long(task:long) Description Return the state of the given task, one of: TASK_RUNNING (0), TASK_INTERRUPTIBLE (1), TASK_UNINTERRUPTIBLE (2), TASK_STOPPED (4), TASK_TRACED (8), EXIT_ZOMBIE (16), EXIT_DEAD (32).

Commands:
function task_state:long(task:long)
D.5. Troubleshooting Matching Rules International collation order matching rules may not behave consistently. Some forms of matching-rule invocation do not work correctly, producing incorrect search results. For example, the following rules do not work: However, the rules listed below will work (note the .3 before the passin value):

Commands:
ldapsearch -x -p 389 -D "uid= userID ,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:2.16.840.1.113730.3.3.2.7.1:=passin" ldapsearch -x -p 389 -D "uid= userID ,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:de:=passin"
ldapsearch -x -p 389 -D "uid= userID ,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:2.16.840.1.113730.3.3.2.7.1 .3 :=passin" ldapsearch -x -p 389 -D "uid= userID ,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:de .3 :=passin"
3.4. Extension Metadata You can use the extension metadata property data-ttl as a model property or on a source table to indicate a default TTL. A negative value means no TTL, 0 means do not cache, and a positive number indicates the time to live in milliseconds. If no TTL is specified on the table, then the schema will be checked. The TTL for the cache entry will be taken as the least positive value among all TTLs. Thus setting this value as a model property can quickly disable any caching against a particular source. Here is an example that shows you how to set the property in the vdb.xml :

Commands:
<vdb name="vdbname" version="1"> <model name="Customers"> <property name="teiid_rel:data-ttl" value="0"/> ...</para>
Appendix C. Configuring a Jenkins freestyle project to deploy your Node.js application with nodeshift Similar to using nodeshift from your local host to deploy a Node.js application, you can configure Jenkins to use nodeshift to deploy a Node.js application. Prerequisites Access to an OpenShift cluster. The Jenkins container image running on same OpenShift cluster. The Node.js plugin installed on your Jenkins server. A Node.js application configured to use nodeshift and the Red Hat base image. Example using the Red Hat base image with nodeshift USD nodeshift --dockerImage=registry.access.redhat.com/rhscl/ubi8/nodejs-12 ... The source of the application available in GitHub. Procedure Create a new OpenShift project for your application: Open the OpenShift Web console and log in. Click Create Project to create a new OpenShift project. Enter the project information and click Create . Ensure Jenkins has access to that project. For example, if you configured a service account for Jenkins, ensure that account has edit access to the project of your application. Create a new freestyle Jenkins project on your Jenkins server: Click New Item . Enter a name, choose Freestyle project , and click OK . Under Source Code Management , choose Git and add the GitHub url of your application. Under Build Environment , make sure Provide Node & npm bin/ folder to PATH is checked and the Node.js environment is configured. Under Build , choose Add build step and select Execute Shell . Add the following to the Command area: npm install -g nodeshift nodeshift --dockerImage=registry.access.redhat.com/rhscl/ubi8/nodejs-12 --namespace=MY_PROJECT Substitute MY_PROJECT with the name of the OpenShift project for your application. Click Save . Click Build Now from the main page of the Jenkins project to verify your application builds and deploys to the OpenShift project for your application. You can also verify that your application is deployed by opening the route in the OpenShift project of the application. steps Consider adding GITSCM polling or using the Poll SCM build trigger . These options enable builds to run every time a new commit is pushed to the GitHub repository. Consider adding nodeshift as a global package when configuring the Node.js plugin . This allows you to omit npm install -g nodeshift when adding your Execute Shell build step. Consider adding a build step that executes tests before deploying.

Commands:
nodeshift --dockerImage=registry.access.redhat.com/rhscl/ubi8/nodejs-12
npm install -g nodeshift nodeshift --dockerImage=registry.access.redhat.com/rhscl/ubi8/nodejs-12 --namespace=MY_PROJECT
28.4.2. Standard ABRT Installation Supported Events Standard ABRT installation currently provides a number of default analyzing, collecting and reporting events. Some of these events are also configurable using the ABRT GUI application (for more information on event configuration using ABRT GUI, see Section 28.4.3, "Event Configuration in ABRT GUI" ). ABRT GUI only shows the event's unique part of the name which is more readable the user, instead of the complete event name. For example, the analyze_xsession_errors event is shown as Collect .xsession-errors in ABRT GUI. The following is a list of default analyzing, collecting and reporting events provided by the standard installation of ABRT : analyze_VMcore - Analyze VM core Runs GDB (the GNU debugger) on problem data of an application and generates a backtrace of the kernel. It is defined in the /etc/libreport/events.d/vmcore_event.conf configuration file. analyze_LocalGDB - Local GNU Debugger Runs GDB (the GNU debugger) on problem data of an application and generates a backtrace of a program. It is defined in the /etc/libreport/events.d/ccpp_event.conf configuration file. analyze_xsession_errors - Collect .xsession-errors Saves relevant lines from the ~/.xsession-errors file to the problem report. It is defined in the /etc/libreport/events.d/ccpp_event.conf configuration file. report_Logger - Logger Creates a problem report and saves it to a specified local file. It is defined in the /etc/libreport/events.d/print_event.conf configuration file. report_RHTSupport - Red Hat Customer Support Reports problems to the Red Hat Technical Support system. This possibility is intended for users of Red Hat Enterprise Linux. It is defined in the /etc/libreport/events.d/rhtsupport_event.conf configuration file. report_Mailx - Mailx Sends a problem report via the Mailx utility to a specified email address. It is defined in the /etc/libreport/events.d/mailx_event.conf configuration file. report_Kerneloops - Kerneloops.org Sends a kernel problem to the oops tracker. It is defined in the /etc/libreport/events.d/koops_event.conf configuration file. report_Uploader - Report uploader Uploads a tarball (.tar.gz) archive with problem data to the chosen destination using the FTP or the SCP protocol. It is defined in the /etc/libreport/events.d/uploader_event.conf configuration file.

Commands:
5.308. spice-protocol 5.308.1. RHEA-2012:0760 - spice-protocol enhancement update An updated spice-protocol package that adds several enhancements is now available for Red Hat Enterprise Linux 6. The spice-protocol package contains header files that describe the SPICE protocol and the QXL para-virtualized graphics card. The SPICE protocol is needed to build newer versions of the spice-client and the spice-server packages. BZ# 758088 The spice-protocol package has been upgraded to upstream version 0.10.1, which provides a number of enhancements over the version, including support for USB redirection. All users who build spice packages are advised to upgrade to this updated package, which adds these enhancements.

Commands:
Chapter 1. Getting started overview Use Red Hat Streams for Apache Kafka to create and set up Kafka clusters, then connect your applications and services to those clusters. This guide describes how to install and start using Streams for Apache Kafka on OpenShift Container Platform. You can install the Streams for Apache Kafka operator directly from the OperatorHub in the OpenShift web console. The Streams for Apache Kafka operator understands how to install and manage Kafka components. Installing from the OperatorHub provides a standard configuration of Streams for Apache Kafka that allows you to take advantage of automatic updates. When the Streams for Apache Kafka operator is installed, it provides the resources to install instances of Kafka components. After installing a Kafka cluster, you can start producing and consuming messages. Note If you require more flexibility with your deployment, you can use the installation artifacts provided with Streams for Apache Kafka. For more information on using the installation artifacts, see Deploying and Managing Streams for Apache Kafka on OpenShift . 1.1. Prerequisites The following prerequisites are required for getting started with Streams for Apache Kafka. You have a Red Hat account. JDK 11 or later is installed. An OpenShift 4.14 and later cluster is available. The OpenShift oc command-line tool is installed and configured to connect to the running cluster. The steps to get started are based on using the OperatorHub in the OpenShift web console, but you'll also use the OpenShift oc CLI tool to perform certain operations. You'll need to connect to your OpenShift cluster using the oc tool. You can install the oc CLI tool from the web console by clicking the '?' help menu, then Command Line Tools . You can copy the required oc login details from the web console by clicking your profile name, then Copy login command . 1.2. Additional resources Streams for Apache Kafka Overview Deploying and Upgrading Streams for Apache Kafka on OpenShift

Commands:
Chapter 6. Managing DNS Using Capsule Satellite can manage DNS records using your Capsule. DNS management contains updating and removing DNS records from existing DNS zones. A Capsule has multiple DNS providers that you can use to integrate Satellite with your existing DNS infrastructure or deploy a new one. After you have enabled DNS, your Capsule can manipulate any DNS server that complies with RFC 2136 using the dns_nsupdate provider. Other providers provide more direct integration, such as dns_infoblox for Infoblox . Available DNS Providers dns_infoblox - For more information, see Using Infoblox as DHCP and DNS Providers in Provisioning Hosts . dns_nsupdate - Dynamic DNS update using nsupdate. For more information, see Using Infoblox as DHCP and DNS Providers in Provisioning Hosts . dns_nsupdate_gss - Dynamic DNS update with GSS-TSIG. For more information, see Section 4.4.1, "Configuring Dynamic DNS Update with GSS-TSIG Authentication" .

Commands:
4.5.2. Virtualization Optimizations Because KVM utilizes kernel functionality, KVM-based virtualized guests immediately benefit from all bare-metal optimizations. Red Hat Enterprise Linux also includes a number of enhancements to allow virtualized guests to approach the performance level of a bare-metal system. These enhancements focus on the I/O path in storage and network access, allowing even intensive workloads such as database and file-serving to make use of virtualized deployment. NUMA-specific enhancements that improve the performance of virtualized systems include: CPU pinning Virtual guests can be bound to run on a specific socket in order to optimize local cache use and remove the need for expensive inter-socket communications and remote memory access. transparent hugepages (THP) With THP enabled, the system automatically performs NUMA-aware memory allocation requests for large contiguous amounts of memory, reducing both lock contention and the number of translation lookaside buffer (TLB) memory management operations required and yielding a performance increase of up to 20% in virtual guests. kernel-based I/O implementation The virtual guest I/O subsystem is now implemented in the kernel, greatly reducing the expense of inter-node communication and memory access by avoiding a significant amount of context switching, and synchronization and communication overhead.

Commands:
4.11. RHEA-2012:0825 - new package: ledmon A new ledmon package is now available for Red Hat Enterprise Linux 6. The ledmon and ledctl utilities are user space applications designed to control LEDs associated with each slot in an enclosure or a drive bay. There are two types of systems: 2-LED system (Activity LED, Status LED) and 3-LED system (Activity LED, Locate LED, Fail LED). Users must have root privileges to use this application. This enhancement update adds the ledmon package to Red Hat Enterprise Linux 6. (BZ# 750379 ) All users who require ledmon are advised to install this new package.

Commands: