mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. System Monitoring and Kernel 9.1. dracut The dracut tool has replaced the use of mkinitrd . Also, the /etc/modprobe.conf file is no longer used by default in the management of kernel modules, however it can still be used if manually created. Refer to the following for an example usage of the dracut tool: You can find the configuration files for dracut in the configuration directory, /etc/dracut.conf.d .

Commands:
mv /boot/initramfs-USD(uname -r).img /boot/initramfs-USD(uname -r)-old.img dracut --force /boot/initramfs-USD(uname -r).img USD(uname -r)
function::set_kernel_string_n Name function::set_kernel_string_n - Writes a string of given length to kernel memory Synopsis Arguments addr The kernel address to write the string to n The maximum length of the string val The string which is to be written Description Writes the given string up to a maximum given length to a given kernel memory address. Reports an error on string copy fault. Requires the use of guru mode (-g).

Commands:
set_kernel_string_n(addr:long,n:long,val:string)
7.82. ipmitool 7.82.1. RHBA-2015:1351 - ipmitool bug fix update Updated ipmitool packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The ipmitool packages contain a command-line utility for interfacing with devices that support the Intelligent Platform Management Interface (IPMI) specification. IPMI is an open standard for machine health, inventory, and remote power control. Bug Fixes BZ# 878614 Prior to this update, ipmitool could handle only 16-byte-long Sensor Data Repository (SDR) item names. Consequently, listing a sensor with a long name could cause ipmitool to terminate unexpectedly. This update fixes the string identification handling, and the long sensor names are now trimmed correctly. BZ# 903019 Previously, ipmitool could not recognize neither sensor thresholds and presence, nor fan units of sensors on Sun Fire X4600 M2 Servers. This update resolves the unrecognized sensor reporting. BZ# 1028163 Previously, the ipmitool default timeout values set an insufficient time period. As a consequence, during retries, ipmitool could terminate unexpectedly with a segmentation fault, or produce a nonsensical error message. With this update, the ipmitool options passed from the environment variable are parsed correctly from the IPMITOOL_OPTS and IPMI_OPTS variables, and IPMITOOL_* variables take precedence over IPMI_* variables. As a result, ipmitool no longer crashes in the described situation. BZ# 1126333 Previously, ipmitool could not recognize the Sensor Data Repository (SDR) type Software ID. As a consequence, the default 5-second timeout for each affected line reported resulted in a very slow response. This update fixes the Intelligent Platform Management Bus (IPMB) request setup, and slow SDR access times are no longer experienced in the described situation. BZ# 1162175 Previously, the ipmitool utility required an unnecessary dependency on the OpenIPMI packages, which had to be installed together with ipmitool. This update removes the dependency on the OpenIPMI packages, which are no longer installed when installing ipmitool. BZ# 1170266 An earlier version of ipmitool contained a version mismatch between the ipmitool packages and the runtime-reported version. Consequently, running the "ipmitool -V" command displayed the 1.8.14 version number instead of the correct 1.8.11 version number. With this update, the runtime version change has been reverted to match the package version. BZ# 1194420 Previously, ipmitool could not recognize DDR4 memory modules and could terminate unexpectedly with a segmentation fault on such systems. This update adds support for DDR4 reporting. As a result, ipmitool no longer crashes on DDR4 systems when running the Field Replacement Unit (FRU) inventory listing. Users of ipmitool are advised to upgrade to these updated packages, which fix these bugs. After installing this update, the IPMI event daemon (ipmievd) will be restarted automatically.

Commands:
8.5. Yum Plug-ins Yum provides plug-ins that extend and enhance its operations. Certain plug-ins are installed by default. Yum always informs you which plug-ins, if any, are loaded and active whenever you call any yum command. For example: Note that the plug-in names which follow Loaded plugins are the names you can provide to the --disableplugins= plugin_name option. 8.5.1. Enabling, Configuring, and Disabling Yum Plug-ins To enable Yum plug-ins, ensure that a line beginning with plugins= is present in the [main] section of /etc/yum.conf , and that its value is 1 : You can disable all plug-ins by changing this line to plugins=0 . Important Disabling all plug-ins is not advised because certain plug-ins provide important Yum services. In particular, rhnplugin provides support for RHN Classic , and product-id and subscription-manager plug-ins provide support for the certificate-based Content Delivery Network ( CDN ). Disabling plug-ins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem with Yum . Every installed plug-in has its own configuration file in the /etc/yum/pluginconf.d/ directory. You can set plug-in specific options in these files. For example, here is the refresh-packagekit plug-in's refresh-packagekit.conf configuration file: Plug-in configuration files always contain a [main] section (similar to Yum's /etc/yum.conf file) in which there is (or you can place if it is missing) an enabled= option that controls whether the plug-in is enabled when you run yum commands. If you disable all plug-ins by setting enabled=0 in /etc/yum.conf , then all plug-ins are disabled regardless of whether they are enabled in their individual configuration files. If you merely want to disable all Yum plug-ins for a single yum command, use the --noplugins option. If you want to disable one or more Yum plug-ins for a single yum command, add the --disableplugin= plugin_name option to the command. For example, to disable the presto plug-in while updating a system, type: The plug-in names you provide to the --disableplugin= option are the same names listed after the Loaded plugins line in the output of any yum command. You can disable multiple plug-ins by separating their names with commas. In addition, you can match multiple plug-in names or shorten long ones by using glob expressions:

Commands:
~]# yum info yum Loaded plugins: product-id, refresh-packagekit, subscription-manager [output truncated]
plugins=1
[main] enabled=1
~]# yum update --disableplugin=presto
~]# yum update --disableplugin=presto,refresh-pack*
Chapter 6. Cache Modes Red Hat JBoss Data Grid provides two modes: Local mode is the only non-clustered cache mode offered in JBoss Data Grid. In local mode, JBoss Data Grid operates as a simple single-node in-memory data cache. Local mode is most effective when scalability and failover are not required and provides high performance in comparison with clustered modes. Clustered mode replicates state changes to a small subset of nodes. The subset size is sufficient for fault tolerance purposes but not large enough to hinder scalability. Before attempting to use clustered mode, it is important to first configure JGroups for a clustered configuration. For details about configuring JGroups, see Section 26.2, "Configure JGroups (Library Mode)" Report a bug 6.1. About Cache Containers Cache containers are used in Red Hat JBoss Data Grid's Remote Client-Server mode as a starting point for a cache. The cache-container element acts as a parent of one or more (local or clustered) caches. To add clustered caches to the container, transport must be defined. The following procedure demonstrates a sample cache container configuration: Procedure 6.1. How to Configure the Cache Container Configure the Cache Container The cache-container element specifies information about the cache container using the following parameters: The name parameter defines the name of the cache container. The default-cache parameter defines the name of the default cache used with the cache container. The statistics attribute is optional and is true by default. Statistics are useful in monitoring JBoss Data Grid via JMX or JBoss Operations Network, however they adversely affect performance. Disable this attribute by setting it to false if it is not required. The listener-executor defines the executor used for asynchronous cache listener notifications. The start parameter indicates when the cache container starts, i.e. whether it will start lazily when requested or "eagerly" when the server starts up. Valid values for this parameter are EAGER and LAZY . Configure Per-cache Statistics If statistics are enabled at the container level, per-cache statistics can be selectively disabled for caches that do not require monitoring by setting the statistics attribute to false . Report a bug

Commands:
<subsystem xmlns="urn:infinispan:server:core:6.2" default-cache-container="local"> <cache-container name="local" default-cache="default" statistics="true" listener-executor="infinispan-listener" start="EAGER"> <local-cache name="default" start="EAGER" statistics="false"> <!-- Additional configuration information here --> </local-cache> </cache-container> </subsystem>
2.4.3. Monitoring Memory If there is one area where a wealth of performance statistics can be found, it is in the area of monitoring memory utilization. Due to the inherent complexity of today's demand-paged virtual memory operating systems, memory utilization statistics are many and varied. It is here that the majority of a system administrator's work with resource management takes place. The following statistics represent a cursory overview of commonly-found memory management statistics: Page Ins/Page Outs These statistics make it possible to gauge the flow of pages from system memory to attached mass storage devices (usually disk drives). High rates for both of these statistics can mean that the system is short of physical memory and is thrashing , or spending more system resources on moving pages into and out of memory than on actually running applications. Active/Inactive Pages These statistics show how heavily memory-resident pages are used. A lack of inactive pages can point toward a shortage of physical memory. Free, Shared, Buffered, and Cached Pages These statistics provide additional detail over the more simplistic active/inactive page statistics. By using these statistics, it is possible to determine the overall mix of memory utilization. Swap Ins/Swap Outs These statistics show the system's overall swapping behavior. Excessive rates here can point to physical memory shortages. Successfully monitoring memory utilization requires a good understanding of how demand-paged virtual memory operating systems work. While such a subject alone could take up an entire book, the basic concepts are discussed in Chapter 4, Physical and Virtual Memory . This chapter, along with time spent actually monitoring a system, gives you the the necessary building blocks to learn more about this subject.

Commands:
Chapter 2. Installing automation content navigator on RHEL As a content creator, you can install automation content navigator on Red Hat Enterprise Linux (RHEL) 8.6 or later. 2.1. Installing automation content navigator on RHEL from an RPM You can install automation content navigator on Red Hat Enterprise Linux (RHEL) from an RPM. Prerequisites You have installed Python 3.10 or later. You have installed RHEL 8.6 or later. You registered your system with Red Hat Subscription Manager. Note Ensure that you only install the navigator matching your current Red Hat Ansible Automation Platform environment. Procedure Attach the Red Hat Ansible Automation Platform SKU: USD subscription-manager attach --pool=<sku-pool-id> Install automation content navigator with the following command: v.2.5 for RHEL 8 for x86_64 USD sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-8-x86_64-rpms ansible-navigator v.2.5 for RHEL 9 for x86-64 USD sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-navigator Verification Verify your automation content navigator installation: USD ansible-navigator --help The following example demonstrates a successful installation:

Commands:
subscription-manager attach --pool=<sku-pool-id>
sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-8-x86_64-rpms ansible-navigator
sudo dnf install --enablerepo=ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms ansible-navigator
ansible-navigator --help
Chapter 1. Operators overview Operators are among the most important components of OpenShift Container Platform. They are the preferred method of packaging, deploying, and managing services on the control plane. They can also provide advantages to applications that users run. Operators integrate with Kubernetes APIs and CLI tools such as kubectl and the OpenShift CLI ( oc ). They provide the means of monitoring applications, performing health checks, managing over-the-air (OTA) updates, and ensuring that applications remain in your specified state. Operators are designed specifically for Kubernetes-native applications to implement and automate common Day 1 operations, such as installation and configuration. Operators can also automate Day 2 operations, such as autoscaling up or down and creating backups. All of these activities are directed by a piece of software running on your cluster. While both follow similar Operator concepts and goals, Operators in OpenShift Container Platform are managed by two different systems, depending on their purpose: Cluster Operators Managed by the Cluster Version Operator (CVO) and installed by default to perform cluster functions. Optional add-on Operators Managed by Operator Lifecycle Manager (OLM) and can be made accessible for users to run in their applications. Also known as OLM-based Operators . 1.1. For developers As an Operator author, you can perform the following development tasks for OLM-based Operators: Install Operator SDK CLI . Create Go-based Operators , Ansible-based Operators , Java-based Operators , and Helm-based Operators . Use Operator SDK to build, test, and deploy an Operator . Install and subscribe an Operator to your namespace . Create an application from an installed Operator through the web console . Additional resources Machine deletion lifecycle hook examples for Operator developers 1.2. For administrators As a cluster administrator, you can perform the following administrative tasks for OLM-based Operators: Manage custom catalogs . Allow non-cluster administrators to install Operators . Install an Operator from OperatorHub . View Operator status . Manage Operator conditions . Upgrade installed Operators . Delete installed Operators . Configure proxy support . Use Operator Lifecycle Manager on restricted networks . For information about the cluster Operators that Red Hat provides, see Cluster Operators reference . 1.3. steps To understand more about Operators, see What are Operators?

Commands:
3.4. Comparison of virt-install and virt-manager Installation options This table provides a quick reference to compare equivalent virt-install and virt-manager installation options for when installing a virtual machine. Most virt-install options are not required. The minimum requirements are --name , --memory , guest storage ( --disk , --filesystem or --disk none ), and an install method ( --location , --cdrom , --pxe , --import , or boot ). These options are further specified with arguments; to see a complete list of command options and related arguments, enter the following command: In virt-manager , at minimum, a name, installation method, memory (RAM), vCPUs, storage are required. Table 3.1. virt-install and virt-manager configuration comparison for guest installations Configuration on virtual machine virt-install option virt-manager installation wizard label and step number Virtual machine name --name, -n Name (step 5) RAM to allocate (MiB) --ram, -r Memory (RAM) (step 3) Storage - specify storage media --disk Enable storage for this virtual machine Create a disk image on the computer's hard drive, or Select managed or other existing storage (step 4) Storage - export a host directory to the guest --filesystem Enable storage for this virtual machine Select managed or other existing storage (step 4) Storage - configure no local disk storage on the guest --nodisks Deselect the Enable storage for this virtual machine check box (step 4) Installation media location (local install) --file Local install media Locate your install media (steps 1-2) Installation using a distribution tree (network install) --location Network install URL (steps 1-2) Install guest with PXE --pxe Network boot (step 1) Number of vCPUs --vcpus CPUs (step 3) Host network --network Advanced options drop-down menu (step 5) Operating system variant/version --os-variant Version (step 2) Graphical display method --graphics, --nographics * virt-manager provides GUI installation only

Commands:
virt-install --help
4.3. Virtualization Under some circumstances, installation of a Red Hat Enterprise Linux 6 virtual guest stalls after the optional testing of media. Note that this issue has only been observed with Red Hat Enterprise Linux 6 guests that utilize multiple virtualized CPUs. To work around this issue, use a media source that is known to be verified, and skip the media test, or use a single virtualized CPU during installation. In earlier versions of Red Hat Enterprise Linux, libvirt permitted PCI devices to be insecurely assigned to guests. In Red Hat Enterprise Linux 6, assignment of insecure devices is disabled by default by libvirt. However, this may cause assignment of previously working devices to start failing. To enable the old, insecure setting, edit /etc/libvirt/qemu.conf, set "relaxed_acs_check = 1", and restart libvirtd. Note that this action will re-open possible security issues. The balloon service on Windows 7 guests can only be started by the "Administrator" user. Libvirt uses transient iptables rules for managing NAT or bridging to virtual machine guests. Any external command that reloads iptables state ( such as running system-config-firewall) will overwrite the entries needed by libvirt. Consequently, after running any command or tool that changes the state of iptables, guests may lose access the network. To work around this issue, use the command 'service libvirt reload' to restore libvirt's additional iptables rules. KVM users with a mix of virtio and ata disks should verify the boot device that anaconda chooses during installation. To verify the boot device, locate the "Install Target Devices" list in the disk selection screen that follows the partitioning type screen. Verify the boot device selection, which is indicated by a selector in the left-most column of the "Install Target Devices" list. A Windows virtual machine must be restarted after the installation of the kernel windows driver framework. If the virtual machine is not restarted it may crash when a memory balloon operation is performed. A dual function, 82576 interface (codename: Kawela, PCI Vendor/Device ID: 8086:10c9) cannot have both physical functions (PF's) device-assigned to a Windows 2008 guest. Either physical function can be device assigned to a Windows 2008 guest (PCI function 0 or function 1), but not both. virt-v2v is able to convert guests running on ESX server. A current limitation in virt-v2v means that if an ESX guest has a disk with a snapshot, the snapshot must be on the same datastore as the underlying disk storage. If the snapshot and underlying storage are on different datastores, virt-v2v will report a 404 error while trying to retrieve the storage. VMware Tools on Microsoft Windows is unable to disable itself when it detects that it is no longer running on a VMware platform. Consequently, converting a Microsoft Windows guest from VMware ESX which has VMware Tools installed will result in errors. These errors usually manifest as error messages on startup, and a "Stop Error" (also known as a BSOD) when shuting down the guest. To work around this issue, uninstall VMware Tools on Microsoft Windows guests prior to conversion.

Commands:
Chapter 1. Available tools with the API Representational State Transfer (REST) relies on a stateless, client-server, and cacheable communications protocol, usually the HTTP protocol. You might find it helpful to see which API calls the user interface makes in sequence. To do this, you can use the UI from Firebug or Chrome with developer plugins. Another option is to use Charles Proxy . This offers a visualizer that you might find helpful. While it is commercial software, it can insert itself as an operating system X proxy and intercept both requests from web browsers, curl and other API consumers. Further options include the following: Fiddler mitmproxy Live HTTP headers FireFox extension Paros

Commands:
Chapter 4. Uninstalling a cluster on Nutanix You can remove a cluster that you deployed to Nutanix. 4.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
Chapter 10. Connecting an event source to a function Functions are deployed as Knative services on an OpenShift Container Platform cluster. You can connect functions to Knative Eventing components so that they can receive incoming events. 10.1. Connect an event source to a function using the Developer perspective Functions are deployed as Knative services on an OpenShift Container Platform cluster. When you create an event source by using the OpenShift Container Platform web console, you can specify a deployed function that events are sent to from that source. Prerequisites The OpenShift Serverless Operator, Knative Serving, and Knative Eventing are installed on your OpenShift Container Platform cluster. You have logged in to the web console and are in the Developer perspective. You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform. You have created and deployed a function. Procedure Create an event source of any type, by navigating to +Add Event Source and selecting the event source type that you want to create. In the Target section of the Create Event Source form view, select your function in the Resource list. Click Create . Verification You can verify that the event source was created and is connected to the function by viewing the Topology page. In the Developer perspective, navigate to Topology . View the event source and click the connected function to see the function details in the right panel.

Commands: