mtpti5iD/redhat-docs_dataset huggingface dataset:
2.6. Networking NetworkManager component To ensure that RFC3442-standard classless static routes provided by a DHCP server are processed correctly when using NetworkManager, the following lines should be placed into the /etc/dhclient.conf file or, if using per-interface DHCP options, the /etc/dhclient-<ifname>.conf file: The above lines will ensure that RFC3442 classless static routes are requested from the DHCP server, and that they are properly processed by NetworkManager. iprutils component Users of the IBM PCI-E Gen2 6GB SAS RADI adapter (FC 5913) in Red Hat Enterprise Linux 6.2 may encounter the following issues: Updating firmware on a storage drawer that is connected to the adapter mentioned above using the iprconfig command fails. Attempting to change the asymmetric access for an array results in a failure. Additionally, not specifying asymmetric access as an option to the iprconfig command results in a failure as well.

Commands:
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; option ms-classless-static-routes code 249 = array of unsigned integer 8; also request rfc3442-classless-static-routes; also request ms-classless-static-routes;
29.5.3. Getting more detailed output on the modules OProfile collects data on a system-wide basis for kernel- and user-space code running on the machine. However, once a module is loaded into the kernel, the information about the origin of the kernel module is lost. The module could have come from the initrd file on boot up, the directory with the various kernel modules, or a locally created kernel module. As a result, when OProfile records sample for a module, it just lists the samples for the modules for an executable in the root directory, but this is unlikely to be the place with the actual code for the module. You will need to take some steps to make sure that analysis tools get the executable. To get a more detailed view of the actions of the module, you will need to either have the module "unstripped" (that is installed from a custom build) or have the debuginfo package installed for the kernel. Find out which kernel is running with the uname -a command, obtain the appropriate debuginfo package and install it on the machine. Then proceed with clearing out the samples from runs with the following command: To start the monitoring process, for example, on a machine with Westmere processor, run the following command: Then the detailed information, for instance, for the ext4 module can be obtained with:

Commands:
~]# opcontrol --reset
~]# opcontrol --setup --vmlinux=/usr/lib/debug/lib/modules/`uname -r`/vmlinux --event=CPU_CLK_UNHALTED:500000
~]# opreport /ext4 -l --image-path /lib/modules/`uname -r`/kernel CPU: Intel Westmere microarchitecture, speed 2.667e+06 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 500000 warning: could not check that the binary file /lib/modules/2.6.32-191.el6.x86_64/kernel/fs/ext4/ext4.ko has not been modified since the profile was taken. Results may be inaccurate. samples % symbol name 1622 9.8381 ext4_iget 1591 9.6500 ext4_find_entry 1231 7.4665 __ext4_get_inode_loc 783 4.7492 ext4_ext_get_blocks 752 4.5612 ext4_check_dir_entry 644 3.9061 ext4_mark_iloc_dirty 583 3.5361 ext4_get_blocks 583 3.5361 ext4_xattr_get 479 2.9053 ext4_htree_store_dirent 469 2.8447 ext4_get_group_desc 414 2.5111 ext4_dx_find_entry
2.4. External Materialization and Red Hat JBoss Data Grid Red Hat JBoss Data Grid can be used as an external materialized data source system in order to improve query result performance. You can use a JDBC data source for the same reason. Note You can also define the materialization through a dynamic VDB. To learn how, look at the [EAP_HOME]/quickstarts/jdg7.1-remote-cache-materialization quick start. Important When DDL metadata changes, the only way to promote the change is restart the Red Hat JBoss Data Grid instance. This also impacts VDB versioning. Important You cannot query a cache if it contains multiple pojos. 2.4.1. Materializing a View Prerequisites You must have two caches and the teiid-alias-naming-cache in Red Hat JBoss Data Grid. (The teiid-alias-naming-cache only needs to be created once because it is shared across all the materializations stored in the Red Hat JBoss Data Grid instance.) Using Teiid Designer, click on a view that is to be materialized. Note Make sure the view has a primary key defined as the Red Hat JBoss Data Grid source table needs one for updates. Otherwise, you will need to manually create a primary key on each of the new JDG source tables. Right-click on the view and click Modeling -> Materialize . Enter the primary and staging cache names. Optionally, you can change the JDGSource model name and the directory in which the model is saved. Note Red Hat JBoss Data Grid restricts the name of the source model because the protobuf code is based on the Java package naming constraints. The model name becomes the package name in the .proto file. This is due to a limitation in the way that the protobuf is defined. Because Red Hat JBoss Data Grid uses Java, the package name must follow the Java package naming standards. Dashes, for instance, are not allowed. Click Finish . To control the materialization process, update the materialized view extension properties on the above selected view: MATVIEW_TTL - to set the refresh rate, in milliseconds If the materialization management status table is used, then set the following extension properties: ALLOW_MATVIEW_MANAGEMENT = true MATVIEW_STATUS_TABLE = {status table name} Create the VDB, using the models needed for materialization. For the JDGSource model, be sure the JNDI is mapped to the JDG data source. Also, enable native queries. To do this, create a translator override for the infinispan-hotrod translator. Click the supportsDirectQueryProcedure property and set the value to true . Deploy the VDB.

Commands:
Chapter 2. Disaster recovery subscription requirement Disaster Recovery features supported by Red Hat OpenShift Data Foundation require all of the following prerequisites to successfully implement a disaster recovery solution: A valid Red Hat OpenShift Data Foundation Advanced entitlement A valid Red Hat Advanced Cluster Management for Kubernetes subscription Any Red Hat OpenShift Data Foundation Cluster containing PVs participating in active replication, either as a source or destination, requires OpenShift Data Foundation Advanced entitlement. This subscription should be active on both source and destination clusters. To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions .

Commands:
Appendix D. Host Parameter Hierarchy You can access host parameters when provisioning hosts. Hosts inherit their parameters from the following locations, in order of increasing precedence: Parameter Level Set in Satellite web UI Globally defined parameters Configure > Global parameters Organization-level parameters Administer > Organizations Location-level parameters Administer > Locations Domain-level parameters Infrastructure > Domains Subnet-level parameters Infrastructure > Subnets Operating system-level parameters Hosts > Operating Systems Host group-level parameters Configure > Host Groups Host parameters Hosts > All Hosts

Commands:
16.5. Creating PAM Modules New PAM modules can be added at any time for PAM-aware applications to use. For example, if a developer invents a one-time-password creation method and writes a PAM module to support it, PAM-aware programs can immediately use the new module and password method without being recompiled or otherwise modified. This allows developers and system administrators to mix-and-match, as well as test, authentication methods for different programs without recompiling them. Documentation on writing modules is included in the /usr/share/doc/pam- <version-number> / directory (where <version-number> is the version number for PAM).

Commands:
Chapter 1. About Pipelines as Code With Pipelines as Code, cluster administrators and users with the required privileges can define pipeline templates as part of source code Git repositories. When triggered by a source code push or a pull request for the configured Git repository, Pipelines as Code runs the pipeline and reports the status. 1.1. Key features Pipelines as Code supports the following features: Pull request status and control on the platform hosting the Git repository. GitHub Checks API to set the status of a pipeline run, including rechecks. GitHub pull request and commit events. Pull request actions in comments, such as /retest . Git events filtering and a separate pipeline for each event. Automatic task resolution in OpenShift Pipelines, including local tasks, Tekton Hub, and remote URLs. Retrieval of configurations using GitHub blobs and objects API. Access Control List (ACL) over a GitHub organization or using a Prow style OWNERS file. The tkn pac CLI plugin for managing bootstrapping and Pipelines as Code repositories. Support for GitHub App, GitHub Webhook, Bitbucket Server, and Bitbucket Cloud.

Commands:
2.12. Unloading Control Groups Warning The cgclear command destroys all cgroups in all hierarchies. If you do not have these hierarchies stored in a configuration file, you will not be able to readily reconstruct them. To clear an entire cgroup file system, use the cgclear command. All tasks in the cgroup are reallocated to the root node of the hierarchies, all cgroups are removed, and the file system itself is unmounted from the system, destroying all previously mounted hierarchies. Finally, the directory where the cgroup file system was mounted is removed. Note Using the mount command to create cgroups (as opposed to creating them using the cgconfig service) results in the creation of an entry in the /etc/mtab file (the mounted file systems table). This change is also reflected in the /proc/mounts file. However, the unloading of cgroups with the cgclear command, along with other cgconfig commands, uses a direct kernel interface which does not reflect its changes into the /etc/mtab file and only writes the new information into the /proc/mounts file. After unloading cgroups with the cgclear command, the unmounted cgroups can still be visible in the /etc/mtab file, and, consequently, displayed when the mount command is executed. Refer to the /proc/mounts file for an accurate listing of all mounted cgroups.

Commands:
B.39.4. RHSA-2011:0356 - Important: krb5 security update Updated krb5 packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link(s) associated with each description below. Kerberos is a network authentication system which allows clients and servers to authenticate to each other using symmetric encryption and a trusted third-party, the Key Distribution Center (KDC). The Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) capability provides support for using public-key authentication with Kerberos. CVE-2011-0284 A double-free flaw was found in the way the MIT Kerberos KDC handled initial authentication requests (AS-REQ), when the KDC was configured to provide the PKINIT capability. A remote attacker could use this flaw to cause the KDC daemon to abort by using a specially-crafted AS-REQ request. All krb5 users should upgrade to these updated packages, which contain a backported patch to correct this issue. After installing the updated packages, the krb5kdc daemon will be restarted automatically.

Commands:
function::sprint_backtrace Name function::sprint_backtrace - Return stack back trace as string. EXPERIMENTAL! Synopsis Arguments None Description Returns a simple (kernel) backtrace. One line per address. Includes the symbol name (or hex address if symbol couldn't be resolved) and module name (if found). Includes the offset from the start of the function if found, otherwise the offset will be added to the module (if found, between brackets). Returns the backtrace as string (each line terminated by a newline character). Note that the returned stack will be truncated to MAXSTRINGLEN, to print fuller and richer stacks use print_backtrace . Equivalent to sprint_stack( backtrace ), but more efficient (no need to translate between hex strings and final backtrace string).

Commands:
function sprint_backtrace:string()
Chapter 1. Red Hat JBoss Data Grid Red Hat JBoss Data Grid is a distributed in-memory data grid, which provides the following capabilities: Schemaless key-value store - JBoss Data Grid is a NoSQL database that provides the flexibility to store different objects without a fixed data model. Grid-based data storage - JBoss Data Grid is designed to easily replicate data across multiple nodes. Elastic scaling - Adding and removing nodes is simple and non-disruptive. Multiple access protocols - It is easy to access the data grid using REST, Memcached, Hot Rod, or simple map-like API. Report a bug 1.1. Supported Configurations The set of supported features, configurations, and integrations for Red Hat JBoss Data Grid (current and past versions) are available at the Supported Configurations page at https://access.redhat.com/articles/115883 . Report a bug

Commands:
Chapter 71. KafkaExporterSpec schema reference Used in: KafkaSpec Property Property type Description image string The container image used for the Kafka Exporter pods. If no image name is explicitly specified, the image name corresponds to the version specified in the Cluster Operator configuration. If an image name is not defined in the Cluster Operator configuration, a default value is used. groupRegex string Regular expression to specify which consumer groups to collect. Default value is .* . topicRegex string Regular expression to specify which topics to collect. Default value is .* . groupExcludeRegex string Regular expression to specify which consumer groups to exclude. topicExcludeRegex string Regular expression to specify which topics to exclude. resources ResourceRequirements CPU and memory resources to reserve. logging string Only log messages with the given severity or above. Valid levels: [ info , debug , trace ]. Default log level is info . livenessProbe Probe Pod liveness check. readinessProbe Probe Pod readiness check. enableSaramaLogging boolean Enable Sarama logging, a Go client library used by the Kafka Exporter. showAllOffsets boolean Whether show the offset/lag for all consumer group, otherwise, only show connected consumer groups. template KafkaExporterTemplate Customization of deployment templates and pods.

Commands:
10.2.4.4. The mod_include Module The mod_include module is now implemented as a filter and is therefore enabled differently. Refer to Section 10.2.4, "Modules and Apache HTTP Server 2.0" for more about filters. For example, the following is a sample Apache HTTP Server 1.3 directive: To migrate this setting to Apache HTTP Server 2.0, use the following structure: Note that the Options +Includes directive is still required for the <Directory> container or in a .htaccess file. 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_include.html

Commands:
AddType text/html .shtml AddHandler server-parsed .shtml
AddType text/html .shtml AddOutputFilter INCLUDES .shtml
Chapter 13. Installing a three-node cluster on GCP In OpenShift Container Platform version 4.14, you can install a three-node cluster on Google Cloud Platform (GCP). A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 13.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 13.2. steps Installing a cluster on GCP with customizations Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
6.3.5. Making a File System and Mounting the New Logical Volume You can make a file system on the new logical volume and mount it.

Commands:
mkfs.gfs2 -plock_nolock -j 1 /dev/yourvg/yourlv This will destroy any data on /dev/yourvg/yourlv. Are you sure you want to proceed? [y/n] y Device: /dev/yourvg/yourlv Blocksize: 4096 Filesystem Size: 1277816 Journals: 1 Resource Groups: 20 Locking Protocol: lock_nolock Lock Table: Syncing All Done mount /dev/yourvg/yourlv /mnt
Chapter 7. Enabling the Red Hat Virtualization Manager Repositories Register the system with Red Hat Subscription Manager, attach the Red Hat Virtualization Manager subscription, and enable Manager repositories. Procedure Register your system with the Content Delivery Network, entering your Customer Portal user name and password when prompted: Note If you are using an IPv6 network, use an IPv6 transition mechanism to access the Content Delivery Network and subscription manager. Find the Red Hat Virtualization Manager subscription pool and record the pool ID: Use the pool ID to attach the subscription to the system: Note To view currently attached subscriptions: To list all enabled repositories: Configure the repositories: The Red Hat Virtualization Manager has been migrated to a self-hosted engine setup. The Manager is now operating on a virtual machine on the new self-hosted engine node. The hosts will be running in the new environment, but cannot host the Manager virtual machine. You can convert some or all of these hosts to self-hosted engine nodes.

Commands:
subscription-manager register
subscription-manager list --available
subscription-manager attach --pool= pool_id
subscription-manager list --consumed
yum repolist
subscription-manager repos --disable='*' --enable=rhel-7-server-rpms --enable=rhel-7-server-supplementary-rpms --enable=rhel-7-server-rhv-4.3-manager-rpms --enable=rhel-7-server-rhv-4-manager-tools-rpms --enable=rhel-7-server-ansible-2.9-rpms --enable=jb-eap-7.2-for-rhel-7-server-rpms
Chapter 6. Connecting to remote Fuse applications The Fuse Console uses Jolokia, an agent-based approach to Java Management Extensions (JMX) that requires extra software (an agent) installed on the client. By default, Red Hat Fuse includes a jolokia agent. With standalone Fuse Console distributions, you can connect to remote integrations that already have a jolokia agent ( https://jolokia.org/ ) running inside them. If the process that you want to connect to does not have a jolokia agent inside, refer to the jolokia documentation ( http://jolokia.org/agent.html ). Procedure The Fuse Console's proxy servlet uses whitelist host protection, with which by default the Fuse Console can only connect to localhost. If you want to connect the Fuse Console to other remote Fuse instances, you need to configure the hawtio.proxyWhitelist system property in the main() method of your Spring Boot application: 6.1. Connecting to a remote Jolokia agent Before you begin, you need to know the connection details (host name, port, and path) of the remote Jolokia agent. The default connection URLs for the Jolokia agent on Spring Boot is http://<host>:8080/jolokia As a system administrator, you can change this default. Typically, the URL to remotely connect to a Jolokia agent is the URL to open the Fuse Console plus /jolokia . For example, if the URL to open the Fuse Console is http://<host>:1234/hawtio , then the URL to remotely connect to it would probably be http://<host>:1234/hawtio/jolokia . To connect to a remote Jolokia instance so that you can examine its JVM: Click the Connect tab. Click the Remote tab, and then Add connection . Type the Name , Scheme (HTTP or HTTPS), and the hostname . Click Test Connection . Click Add . Note The Fuse Console automatically probes the local network interfaces other than localhost and 127.0.0.1 and adds them to the whitelist. Hence, you do not need to manually register the local machine's addresses to the whitelist. 6.2. Setting data moving preferences You can change the following Jolokia preferences, for example, if you want to more frequently refresh data that displays in the Fuse Console. Note that increasing the frequency of data updates impacts networking traffic and increases the number of requests made to the server. Update rate - The period between polls to Jolokia to fetch JMX data (the default is 5 seconds). Maximum depth - The number of levels that Jolokia will marshal an object to JSON on the server side before returning (the default is 7). Maximum collection size - The maximum number of elements in an array that Jolokia marshals in a response (the default is 50,000). To change the values of these settings: In the upper right of the Fuse Console, click the user icon and then click Preferences . Edit the options and then click Close . 6.3. Viewing JVM runtime information To view JVM runtime information, such as system properties, metrics, and threads, click the Runtime tab.

Commands:
System.setProperty("hawtio.proxyWhitelist", "localhost, 127.0.0.1, myhost1, myhost2, myhost3");