mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Verifying HCI configuration After deployment is complete, verify the HCI environment is properly configured. 6.1. Verifying HCI configuration After the deployment of the HCI environment, verify that the deployment was successful with the configuration specified. Procedure Start a ceph shell. Confirm NUMA and memory target configuration: Confirm specific OSD configuration: Confirm specific OSD backfill configuration: Confirm the reserved_host_memory_mb configuration on the Compute node.

Commands:
ceph config dump | grep numa osd advanced osd_numa_auto_affinity true ceph config dump | grep autotune osd advanced osd_memory_target_autotune true ceph config get mgr mgr/cephadm/autotune_memory_target_ratio 0.200000
ceph config get osd.11 osd_memory_target 4294967296 ceph config get osd.11 osd_memory_target_autotune true ceph config get osd.11 osd_numa_auto_affinity true
ceph config get osd.11 osd_recovery_op_priority 3 ceph config get osd.11 osd_max_backfills 1 ceph config get osd.11 osd_recovery_max_active_hdd 3 ceph config get osd.11 osd_recovery_max_active_ssd 10
sudo podman exec -ti nova_compute /bin/bash bash-5.1USD grep reserved_host_memory_mb /etc/nova/nova.conf
Chapter 27. JvmOptions schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , KafkaNodePoolSpec , ZookeeperClusterSpec Property Property type Description -XX map A map of -XX options to the JVM. -Xms string -Xms option to to the JVM. -Xmx string -Xmx option to to the JVM. gcLoggingEnabled boolean Specifies whether the Garbage Collection logging is enabled. The default is false. javaSystemProperties SystemProperty array A map of additional system properties which will be passed using the -D option to the JVM.

Commands:
Chapter 3. Getting started This chapter guides you through the steps to set up your environment and run a simple messaging program. 3.1. Prerequisites To build the example, Maven must be configured to use the Red Hat repository or a local repository . You must install the examples . You must have a message broker listening for connections on localhost . It must have anonymous access enabled. For more information, see Starting the broker . You must have a queue named queue . For more information, see Creating a queue . 3.2. Running Hello World The Hello World example creates a connection to the broker, sends a message containing a greeting to the queue queue, and receives it back. On success, it prints the received message to the console. Procedure Use Maven to build the examples by running the following command in the <source-dir> /qpid-jms-examples directory: USD mvn clean package dependency:copy-dependencies -DincludeScope=runtime -DskipTests The addition of dependency:copy-dependencies results in the dependencies being copied into the target/dependency directory. Use the java command to run the example. On Linux or UNIX: USD java -cp "target/classes:target/dependency/*" org.apache.qpid.jms.example.HelloWorld On Windows: > java -cp "target\classes;target\dependency\*" org.apache.qpid.jms.example.HelloWorld For example, running it on Linux results in the following output: USD java -cp "target/classes/:target/dependency/*" org.apache.qpid.jms.example.HelloWorld Hello world! The source code for the example is in the <source-dir> /qpid-jms-examples/src/main/java directory. The JNDI and logging configuration is in the <source-dir> /qpid-jms-examples/src/main/resources directory.

Commands:
mvn clean package dependency:copy-dependencies -DincludeScope=runtime -DskipTests
java -cp "target/classes:target/dependency/*" org.apache.qpid.jms.example.HelloWorld
> java -cp "target\classes;target\dependency\*" org.apache.qpid.jms.example.HelloWorld
java -cp "target/classes/:target/dependency/*" org.apache.qpid.jms.example.HelloWorld Hello world!
Chapter 2. Configuring the OpenShift Pipelines tkn CLI Configure the Red Hat OpenShift Pipelines tkn CLI to enable tab completion. 2.1. Enabling tab completion After you install the tkn CLI, you can enable tab completion to automatically complete tkn commands or suggest options when you press Tab. Prerequisites You must have the tkn CLI tool installed. You must have bash-completion installed on your local system. Procedure The following procedure enables tab completion for Bash. Save the Bash completion code to a file: USD tkn completion bash > tkn_bash_completion Copy the file to /etc/bash_completion.d/ : USD sudo cp tkn_bash_completion /etc/bash_completion.d/ Alternatively, you can save the file to a local directory and source it from your .bashrc file instead. Tab completion is enabled when you open a new terminal.

Commands:
tkn completion bash > tkn_bash_completion
sudo cp tkn_bash_completion /etc/bash_completion.d/
Chapter 1. About Red Hat CodeReady Workspaces Red Hat CodeReady Workspaces is a web-based integrated development environment (IDE). CodeReady Workspaces runs in OpenShift and is well-suited for container-based development. CodeReady Workspaces provides: an enterprise-level cloud developer workspace server a browser-based IDE ready-to-use developer stacks for popular programming languages, frameworks, and Red Hat technologies Red Hat CodeReady Workspaces 2.15 is based on Eclipse Che 7.42. 1.1. Supported deployment environments This section describes the availability and the supported installation methods of CodeReady Workspaces 2.15 on OpenShift Container Platform 4.10 4.8, 3.11, and OpenShift Dedicated. Table 1.1. Supported deployment environments for CodeReady Workspaces 2.15 on OpenShift Container Platform and OpenShift Dedicated Platform Architecture Deployment method OpenShift Container Platform 3.11 AMD64 and Intel 64 (x86_64) crwctl OpenShift Container Platform 4.8 to 4.10 AMD64 and Intel 64 (x86_64) OperatorHub, crwctl OpenShift Container Platform 4.8 to 4.10 IBM Z (s390x) OperatorHub, crwctl OpenShift Container Platform 4.8 to 4.10 IBM Power (ppc64le) OperatorHub, crwctl OpenShift Dedicated 4.10 AMD64 and Intel 64 (x86_64) Add-on service Red Hat OpenShift Service on AWS (ROSA) AMD64 and Intel 64 (x86_64) Add-on service Additional resources Installing CodeReady Workspaces from Operator Hub on OpenShift 4.10 . Installing CodeReady Workspaces on OpenShift Container Platform 3.11 . 1.2. Support policy For Red Hat CodeReady Workspaces 2.15, Red Hat will provide support for deployment, configuration, and use of the product. CodeReady Workspaces 2.15 has been tested on Chrome version 94.0.4606.81 (Official Build) (64-bit). Additional resources CodeReady Workspaces life-cycle and support policy . 1.3. Differences between Eclipse Che and Red Hat CodeReady Workspaces The main differences between CodeReady Workspaces and Eclipse Che are: CodeReady Workspaces is built on RHEL8 to ensure the latest security fixes are included, compared to Alpine distributions that take a longer time to update. CodeReady Workspaces uses Red Hat Single Sign-On (RH-SSO) rather than the upstream project Keycloak. CodeReady Workspaces provides a smaller supported subset of plug-ins compared to Che. CodeReady Workspaces provides devfiles for working with other Red Hat technologies such as EAP and Fuse. CodeReady Workspaces is supported on OpenShift Container Platform and OpenShift Dedicated; Eclipse Che can run on other Kubernetes clusters. Red Hat provides licensing, packaging, and support. Therefore, CodeReady Workspaces is considered a more stable product than the upstream Eclipse Che project.

Commands:
7.216. rpcbind 7.216.1. RHBA-2013:0291 - rpcbind bug fix and enhancement update Updated rpcbind packages that fix two bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The rpcbind utility maps RPC (Remote Procedure Call) services to the ports on which the services listen and allows the host to make RPC calls to the RPC server. Bug Fixes BZ# 813898 Previously, the rpcbind(8) man page referred to rpcbind(3) for which no entry existed. This update adds the missing rpcbind(3) man page. BZ#864056 Using Reverse Address Resolution Protocol (RARP) and the bootparams file for booting Solaris or SPARC machines did not work properly. The SPARC systems sent broadcast bootparams WHOAMI requests, but the answer was never sent back by rpcbind. This bug has been fixed and rpcbind no longer discards the bootparams WHOAMI requests in the described scenario. Enhancement BZ# 731542 When using the rpcbind's insecure mode via the "-i" option, non-root local users are now allowed to set and unset calls from remote hosts. All users of rpcbind are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 1. Architectures Red Hat Enterprise Linux 7 is available as a single kit on the following architectures [1] : 64-bit AMD 64-bit Intel IBM POWER7 IBM System z [2] In this release, Red Hat brings together improvements for servers and systems, as well as for the overall Red Hat open source experience. [1] Note that the Red Hat Enterprise Linux 7 installation is only supported on 64-bit hardware. Red Hat Enterprise Linux 7 is able to run 32-bit operating systems, including versions of Red Hat Enterprise Linux, as virtual machines. [2] Note that Red Hat Enterprise Linux 7 supports IBM zEnterprise 196 hardware or later; IBM System z10 mainframe systems are no longer supported and will not boot Red Hat Enterprise Linux 7.

Commands:
Chapter 12. Pools 12.1. Introduction to Virtual Machine Pools A virtual machine pool is a group of virtual machines that are all clones of the same template and that can be used on demand by any user in a given group. Virtual machine pools allow administrators to rapidly configure a set of generalized virtual machines for users. Users access a virtual machine pool by taking a virtual machine from the pool. When a user takes a virtual machine from a pool, they are provided with any one of the virtual machines in the pool if any are available. That virtual machine will have the same operating system and configuration as that of the template on which the pool was based, but users may not receive the same member of the pool each time they take a virtual machine. Users can also take multiple virtual machines from the same virtual machine pool depending on the configuration of that pool. Virtual machine pools are stateless by default, meaning that virtual machine data and configuration changes are not persistent across reboots. However, the pool can be configured to be stateful, allowing changes made by a user to persist. However, if a user configures console options for a virtual machine taken from a virtual machine pool, those options will be set as the default for that user for that virtual machine pool. Note Virtual machines taken from a pool are not stateless when accessed from the Administration Portal. This is because administrators need to be able to write changes to the disk if necessary. In principle, virtual machines in a pool are started when taken by a user, and shut down when the user is finished. However, virtual machine pools can also contain pre-started virtual machines. Pre-started virtual machines are kept in an up state, and remain idle until they are taken by a user. This allows users to start using such virtual machines immediately, but these virtual machines will consume system resources even while not in use due to being idle.

Commands:
Chapter 1. Red Hat JBoss Web Server Operator An Operator is a Kubernetes-native application that makes it easy to manage complex stateful applications in Kubernetes and OpenShift environments. Red Hat JBoss Web Server (JWS) provides an Operator to manage JWS for OpenShift images. You can use the JWS Operator to create, configure, manage, and seamlessly upgrade instances of web server applications in OpenShift. Operators include the following key concepts: The Operator Framework is a toolkit to manage Operators in an effective, automated, and scalable way. The Operator Framework consists of three main components: You can use OperatorHub to discover Operators that you want to install. You can use the Operator Lifecycle Manager (OLM) to install and manage Operators in your OpenShift cluster. You can use the Operator SDK if you want to develop your own custom Operators. An Operator group is an OLM resource that provides multitenant configuration to OLM-installed Operators. An Operator group selects target namespaces in which to generate role-based access control (RBAC) for all Operators that are deployed in the same namespace as the OperatorGroup object. Custom resource definitions (CRDs) are a Kubernetes extension mechanism that Operators use. CRDs allow the custom objects that an Operator manages to behave like native Kubernetes objects. The JWS Operator provides a set of CRD parameters that you can specify in custom resource files for web server applications that you want to deploy. This document describes how to install the JWS Operator, deploy an existing JWS image, and delete Operators from a cluster. This document also provides details of the CRD parameters that the JWS Operator provides. Note Before you follow the instructions in this guide, you must ensure that an OpenShift cluster is already installed and configured as a prerequisite. For more information about installing and configuring OpenShift clusters, see the OpenShift Container Platform Installing guide. For a faster but less detailed guide to deploying a prepared image or building an image from an existing image stream, see the JWS Operator QuickStart guide. Important Red Hat supports images for JWS 5.4 or later versions only. Additional resources Understanding Operators Installing and configuring OpenShift Container Platform clusters

Commands:
5.2. Converting to an Ext3 File System The tune2fs command converts an ext2 file system to ext3 . Note A default installation of Red Hat Enterprise Linux uses ext4 for all file systems. However, to convert ext2 to ext3, always use the e2fsck utility to check your file system before and after using tune2fs . Before trying to convert ext2 to ext3, back up all file systems in case any errors occur. In addition, Red Hat recommends creating a new ext3 file system and migrating data to it, instead of converting from ext2 to ext3 whenever possible. To convert an ext2 file system to ext3 , log in as root and type the following command in a terminal: block_device contains the ext2 file system to be converted. A valid block device can be one of two types of entries: A mapped device A logical volume in a volume group, for example, /dev/mapper/VolGroup00-LogVol02 . A static device A traditional storage volume, for example, /dev/ sdb X , where sdb is a storage device name and X is the partition number. Issue the df command to display mounted file systems.

Commands:
tune2fs -j block_device
20.16.13. Video Devices A video device. To specify the video devices configuration settings, use a management tool to make the following changes to the domain XML: ... <devices> <video> <model type='vga' vram='8192' heads='1'> <acceleration accel3d='yes' accel2d='yes'/> </model> </video> </devices> ... Figure 20.58. Video devices The graphics element has a mandatory type attribute which takes the value "sdl", "vnc", "rdp" or "desktop" as explained below: Table 20.22. Graphical framebuffer elements Parameter Description video The video element is the container for describing video devices. For backwards compatibility, if no video is set but there is a graphics element in domain xml, then libvirt will add a default video according to the guest virtual machine type. If "ram" or "vram" are not supplied a default value is used. model This has a mandatory type attribute which takes the value vga , cirrus , vmvga , xen , vbox , or qxl depending on the hypervisor features available. You can also provide the amount of video memory in kibibytes (blocks of 1024 bytes) using vram and the number of figure with heads. acceleration If acceleration is supported it should be enabled using the accel3d and accel2d attributes in the acceleration element. address The optional address sub-element can be used to tie the video device to a particular PCI slot.

Commands:
<devices> <video> <model type='vga' vram='8192' heads='1'> <acceleration accel3d='yes' accel2d='yes'/> </model> </video> </devices>
5.9.7.3. Managing Disk Quotas There is little actual management required to support disk quotas under Red Hat Enterprise Linux. Essentially, all that is required is: Generating disk usage reports at regular intervals (and following up with users that seem to be having trouble effectively managing their allocated disk space) Making sure that the disk quotas remain accurate Creating a disk usage report entails running the repquota utility program. Using the command repquota /home produces this output: More information about repquota can be found in the System Administrators Guide , in the chapter on disk quotas. Whenever a file system is not unmounted cleanly (due to a system crash, for example), it is necessary to run quotacheck . However, many system administrators recommend running quotacheck on a regular basis, even if the system has not crashed. The process is similar to the initial use of quotacheck when enabling disk quotas. Here is an example quotacheck command: The easiest way to run quotacheck on a regular basis is to use cron . Most system administrators run quotacheck once a week, though there may be valid reasons to pick a longer or shorter interval, depending on your specific conditions.

Commands:
*** Report for user quotas on device /dev/md3 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 32836 0 0 4 0 0 matt -- 6618000 6900000 7000000 17397 0 0
quotacheck -avug
20.28. Retrieving Guest Virtual Machine Information 20.28.1. Getting the Domain ID of a Guest Virtual Machine The virsh domid command returns the guest virtual machine's ID. Note that this changes each time the guest starts or restarts. This command requires either the name of the virtual machine or the virtual machine's UUID. Example 20.67. How to retrieve the domain ID for a guest virtual machine The following example retrieves the domain ID of a guest virtual machine named guest1 : Note, domid returns - for guest virtual machines that are in shut off state. To confirm that the virtual machine is shutoff, you can run the virsh list --all command. 20.28.2. Getting the Domain Name of a Guest Virtual Machine The virsh domname command returns the name of the guest virtual machine given its ID or UUID. Note that the ID changes each time the guest starts. Example 20.68. How to retrieve a virtual machine's ID The following example retrieves the name for the guest virtual machine whose ID is 8 : 20.28.3. Getting the UUID of a Guest Virtual Machine The virsh domuuid command returns the UUID or the Universally Unique Identifier for a given guest virtual machine or ID. Example 20.69. How to display the UUID for a guest virtual machine The following example retrieves the UUID for the guest virtual machine named guest1 : 20.28.4. Displaying Guest Virtual Machine Information The virsh dominfo command displays information on that guest virtual machine given a virtual machine's name, ID, or UUID. Note that the ID changes each time the virtual machine starts. Example 20.70. How to display guest virtual machine general details The following example displays the general details about the guest virtual machine named guest1 :

Commands:
virsh domid guest1 8
virsh domname 8 guest1
virsh domuuid guest1 r5b2-mySQL01 4a4c59a7-ee3f-c781-96e4-288f2862f011
virsh dominfo guest1 Id: 8 Name: guest1 UUID: 90e0d63e-d5c1-4735-91f6-20a32ca22c48 OS Type: hvm State: running CPU(s): 1 CPU time: 32.6s Max memory: 1048576 KiB Used memory: 1048576 KiB Persistent: yes Autostart: disable Managed save: no Security model: selinux Security DOI: 0 Security label: system_u:system_r:svirt_t:s0:c552,c818 (enforcing)
5.196. mod_auth_kerb 5.196.1. RHBA-2012:0877 - mod_auth_kerb bug fix and enhancement update Updated mod_auth_kerb packages that fix a bug and add an enhancement are now available for Red Hat Enterprise Linux 6. The mod_auth_kerb package provides a module for the Apache HTTP Server designed to provide Kerberos authentication over HTTP. The module supports the Negotiate authentication method, which performs full Kerberos authentication based on ticket exchanges. Bug Fix BZ# 688210 Due to a bug in the handling of memory lifetime when the module was configured to allow delegated credentials, the USDKRB5CCNAME variable was lost after the first request of an authenticated connection, causing web applications which relied on the presence of delegated credentials to fail. The memory lifetime handling has been fixed, allowing such web applications to access delegated credentials. Enhancement BZ# 767741 Support for "S4U2Proxy" constrained delegation has been added, which allows mod_auth_kerb to obtain credentials on behalf of an authenticated user. Users are advised to upgrade to these updated mod_auth_kerb packages, which fix this bug and add this enhancement.

Commands:
6.3. Performing a Driver Update During Installation You can perform a driver update during installation in the following ways: let the installer automatically find a driver update disk. let the installer prompt you for a driver update. use a boot option to specify a driver update disk. 6.3.1. Let the Installer Find a Driver Update Disk Automatically Attach a block device with the filesystem label OEMDRV before starting the installation process. The installer will automatically examine the device and load any driver updates that it detects and will not prompt you during the process. Refer to Section 6.2.1.1, "Preparing to use an image file on local storage" to prepare a storage device for the installer to find.

Commands:
16.9.2. Installation To install virt-inspector and the documentation, enter the following command: To process Windows guest virtual machines you must also install libguestfs-winsupport . Refer to Section 16.10.2, "Installation" for details. The documentation, including example XML output and a Relax-NG schema for the output, will be installed in /usr/share/doc/libguestfs-devel-*/ where "*" is replaced by the version number of libguestfs.

Commands:
yum install libguestfs-tools libguestfs-devel
Chapter 1. Introduction to SELinux SELinux provides enhanced security by enforcing security policies, using labels for files, processes and ports, and logging unauthorized access attempts. SELinux is enabled and set to enforcing mode on RHEL 9 by default and security policies for system processes are maintained by Red Hat. For more information, refer to Changing SELinux states and modes on RHEL. You can refer to SAP Note 3108302 - SAP HANA DB: Recommended OS Settings for RHEL 9 , to know which HANA versions have been tested by SAP with SELinux set to enforcing and unconfined mode. Red Hat recommends that you use SELinux in enforcing mode to configure your RHEL systems running on SAP HANA. This document describes the necessary configuration changes that you must make. In case you come across SELinux related issues while testing or running your SAP HANA system, SAP reserves the right to disable SELinux. However, most of the problems can be solved by changing SELinux mode from enforcing to permissive . The advantage is that your system is still operating while you analyze and solve the problem.

Commands:
12.2.4. Deleting a Storage Pool Using virsh To avoid any issues with other guest virtual machines using the same pool, it is best to stop the storage pool and release any resources in use by it. Optionally, if you want to remove the directory where the storage pool resides use the following command: Remove the storage pool's definition

Commands:
virsh pool-destroy guest_images_disk
virsh pool-delete guest_images_disk
virsh pool-undefine guest_images_disk