mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. Error handling Errors in Red Hat build of Rhea can be handled by intercepting named events corresponding to AMQP protocol or connection errors. 9.1. Handling connection and protocol errors You can handle protocol-level errors by intercepting the following events: connection_error session_error sender_error receiver_error protocol_error error These events are fired whenever there is an error condition with the specific object that is in the event. After calling the error handler, the corresponding <object> _close handler is also called. The event argument has an error attribute for accessing the error object. Example: Handling errors container.on("error", function (event) { console.log("An error!", event.error); }); Note Because the close handlers are called in the event of any error, only the error itself needs to be handled within the error handler. Resource cleanup can be managed by close handlers. If there is no error handling that is specific to a particular object, it is typical to handle the general error event and not have a more specific handler. Note When reconnect is enabled and the remote server closes a connection with the amqp:connection:forced condition, the client does not treat it as an error and thus does not fire the connection_error event. The client instead begins the reconnection process.

Commands:
container.on("error", function (event) { console.log("An error!", event.error); });
Chapter 9. Consoles and logging during installation The Red Hat Enterprise Linux installer uses the tmux terminal multiplexer to display and control several windows in addition to the main interface. Each of these windows serve a different purpose; they display several different logs, which can be used to troubleshoot issues during the installation process. One of the windows provides an interactive shell prompt with root privileges, unless this prompt was specifically disabled using a boot option or a Kickstart command. The terminal multiplexer is running in virtual console 1. To switch from the actual installation environment to tmux , press Ctrl + Alt + F1 . To go back to the main installation interface which runs in virtual console 6, press Ctrl + Alt + F6 . During the text mode installation, start in virtual console 1 ( tmux ), and switching to console 6 will open a shell prompt instead of a graphical interface. The console running tmux has five available windows; their contents are described in the following table, along with keyboard shortcuts. Note that the keyboard shortcuts are two-part: first press Ctrl + b , then release both keys, and press the number key for the window you want to use. You can also use Ctrl + b n , Alt+ Tab , and Ctrl + b p to switch to the or tmux window, respectively. Table 9.1. Available tmux windows Shortcut Contents Ctrl + b 1 Main installation program window. Contains text-based prompts (during text mode installation or if you use VNC direct mode), and also some debugging information. Ctrl + b 2 Interactive shell prompt with root privileges. Ctrl + b 3 Installation log; displays messages stored in /tmp/anaconda.log . Ctrl + b 4 Storage log; displays messages related to storage devices and configuration, stored in /tmp/storage.log . Ctrl + b 5 Program log; displays messages from utilities executed during the installation process, stored in /tmp/program.log .

Commands:
4.5. Migrating with virt-manager This section covers migrating a KVM guest virtual machine with virt-manager from one host physical machine to another. Open virt-manager Open virt-manager . Choose Applications System Tools Virtual Machine Manager from the main menu bar to launch virt-manager . Figure 4.1. Virt-Manager main menu Connect to the target host physical machine Connect to the target host physical machine by clicking on the File menu, then click Add Connection . Figure 4.2. Open Add Connection window Add connection The Add Connection window appears. Figure 4.3. Adding a connection to the target host physical machine Enter the following details: Hypervisor : Select QEMU/KVM . Method : Select the connection method. Username : Enter the user name for the remote host physical machine. Hostname : Enter the host name for the remote host physical machine. Click the Connect button. An SSH connection is used in this example, so the specified user's password must be entered in the step. Figure 4.4. Enter password Migrate guest virtual machines Open the list of guests inside the source host physical machine (click the small triangle on the left of the host name) and right click on the guest that is to be migrated ( guest1-rhel6-64 in this example) and click Migrate . Figure 4.5. Choosing the guest to be migrated In the New Host field, use the drop-down list to select the host physical machine you wish to migrate the guest virtual machine to and click Migrate . Figure 4.6. Choosing the destination host physical machine and starting the migration process A progress window will appear. Figure 4.7. Progress window virt-manager now displays the newly migrated guest virtual machine running in the destination host. The guest virtual machine that was running in the source host physical machine is now listed inthe Shutoff state. Figure 4.8. Migrated guest virtual machine running in the destination host physical machine Optional - View the storage details for the host physical machine In the Edit menu, click Connection Details , the Connection Details window appears. Click the Storage tab. The iSCSI target details for the destination host physical machine is shown. Note that the migrated guest virtual machine is listed as using the storage Figure 4.9. Storage details This host was defined by the following XML configuration: <pool type='iscsi'> <name>iscsirhel6guest</name> <source> <host name='virtlab22.example.com.'/> <device path='iqn.2001-05.com.iscsivendor:0-8a0906-fbab74a06-a700000017a4cc89-rhevh'/> </source> <target> <path>/dev/disk/by-path</path> </target> </pool> ... Figure 4.10. XML configuration for the destination host physical machine

Commands:
<pool type='iscsi'> <name>iscsirhel6guest</name> <source> <host name='virtlab22.example.com.'/> <device path='iqn.2001-05.com.iscsivendor:0-8a0906-fbab74a06-a700000017a4cc89-rhevh'/> </source> <target> <path>/dev/disk/by-path</path> </target> </pool>
Chapter 10. Incident Response In the event that the security of a system has been compromised, an incident response is necessary. It is the responsibility of the security team to respond to the problem quickly and effectively. 10.1. Defining Incident Response An incident response is an expedited reaction to a security issue or occurrence. Pertaining to information security, an example would be a security team's actions against a hacker who has penetrated a firewall and is currently sniffing internal network traffic. The incident is the breach of security. The response depends upon how the security team reacts, what they do to minimize damages, and when they restore resources, all while attempting to guarantee data integrity. Think of your organization and how almost every aspect of it relies upon technology and computer systems. If there is a compromise, imagine the potentially devastating results. Besides the obvious system downtime and theft of data, there could be data corruption, identity theft (from online personnel records), embarrassing publicity, or even financially devastating results as customers and business partners learn of and react negatively to news of a compromise. Research into past internal and external security breaches shows that some companies go of business as a result of a serious breach of security. A breach can result in resources rendered unavailable and data being either stolen or corrupted. But one cannot overlook issues that are difficult to calculate financially, such as bad publicity. To gain an accurate idea of how important an efficient incident response is, an organization must calculate the cost of the actual security breach as well as the financial effects of the negative publicity over, in the short and long term.

Commands:
6.2. Mounting a btrfs file system To mount any device in the btrfs file system use the following command: Other useful mount options include: device=/ dev / name Appending this option to the mount command tells btrfs to scan the named device for a btrfs volume. This is used to ensure the mount will succeed as attempting to mount devices that are not btrfs will cause the mount to fail. Note This does not mean all devices will be added to the file system, it only scans them. max_inline= number Use this option to set the maximum amount of space (in bytes) that can be used to inline data within a metadata B-tree leaf. The default is 8192 bytes. For 4k pages it is limited to 3900 bytes due to additional headers that need to fit into the leaf. alloc_start= number Use this option to set where in the disk allocations start. thread_pool= number Use this option to assign the number of worker threads allocated. discard Use this option to enable discard/TRIM on freed blocks. noacl Use this option to disable the use of ACL's. space_cache Use this option to store the free space data on disk to make caching a block group faster. This is a persistent change and is safe to boot into old kernels. nospace_cache Use this option to disable the above space_cache . clear_cache Use this option to clear all the free space caches during mount. This is a safe option but will trigger the space cache to be rebuilt. As such, leave the file system mounted in order to let the rebuild process finish. This mount option is intended to be used once and only after problems are apparent with the free space. enospc_debug This option is used to debug problems with "no space left". recovery Use this option to enable autorecovery upon mount.

Commands:
mount / dev / device / mount-point
4.2. Physical Volume Administration This section describes the commands that perform the various aspects of physical volume administration. 4.2.1. Creating Physical Volumes The following subsections describe the commands used for creating physical volumes. 4.2.1.1. Setting the Partition Type If you are using a whole disk device for your physical volume, the disk must have no partition table. For DOS disk partitions, the partition id should be set to 0x8e using the fdisk or cfdisk command or an equivalent. For whole disk devices only the partition table must be erased, which will effectively destroy all data on that disk. You can remove an existing partition table by zeroing the first sector with the following command: 4.2.1.2. Initializing Physical Volumes Use the pvcreate command to initialize a block device to be used as a physical volume. Initialization is analogous to formatting a file system. The following command initializes /dev/sdd1 , /dev/sde1 , and /dev/sdf1 for use as LVM physical volumes. To initialize partitions rather than whole disks: run the pvcreate command on the partition. The following example initializes /dev/hdb1 as an LVM physical volume for later use as part of an LVM logical volume. 4.2.1.3. Scanning for Block Devices You can scan for block devices that may be used as physical volumes with the lvmdiskscan command, as shown in the following example.

Commands:
dd if=/dev/zero of= PhysicalVolume bs=512 count=1
pvcreate /dev/sdd1 /dev/sde1 /dev/sdf1
pvcreate /dev/hdb1
lvmdiskscan /dev/ram0 [ 16.00 MB] /dev/sda [ 17.15 GB] /dev/root [ 13.69 GB] /dev/ram [ 16.00 MB] /dev/sda1 [ 17.14 GB] LVM physical volume /dev/VolGroup00/LogVol01 [ 512.00 MB] /dev/ram2 [ 16.00 MB] /dev/new_vg/lvol0 [ 52.00 MB] /dev/ram3 [ 16.00 MB] /dev/pkl_new_vg/sparkie_lv [ 7.14 GB] /dev/ram4 [ 16.00 MB] /dev/ram5 [ 16.00 MB] /dev/ram6 [ 16.00 MB] /dev/ram7 [ 16.00 MB] /dev/ram8 [ 16.00 MB] /dev/ram9 [ 16.00 MB] /dev/ram10 [ 16.00 MB] /dev/ram11 [ 16.00 MB] /dev/ram12 [ 16.00 MB] /dev/ram13 [ 16.00 MB] /dev/ram14 [ 16.00 MB] /dev/ram15 [ 16.00 MB] /dev/sdb [ 17.15 GB] /dev/sdb1 [ 17.14 GB] LVM physical volume /dev/sdc [ 17.15 GB] /dev/sdc1 [ 17.14 GB] LVM physical volume /dev/sdd [ 17.15 GB] /dev/sdd1 [ 17.14 GB] LVM physical volume 7 disks 17 partitions 0 LVM physical volume whole disks 4 LVM physical volumes
Chapter 5. Managing Satellite with Ansible Satellite Ansible Collections is a set of Ansible modules that interact with the Satellite API. You can manage and automate many aspects of Satellite with Satellite Ansible collections. 5.1. Installing the Satellite Ansible modules Use this procedure to install the Satellite Ansible modules. Procedure Install the package using the following command: 5.2. Viewing the Satellite Ansible modules You can view the installed Satellite Ansible modules by running: Alternatively, you can also see the complete list of Satellite Ansible modules and other related information at Red Hat Ansible Automation Platform . All modules are in the redhat.satellite namespace and can be referred to in the format redhat.satellite._module_name_ . For example, to display information about the activation_key module, enter the following command:

Commands:
satellite-maintain packages install ansible-collection-redhat-satellite
ansible-doc -l redhat.satellite
ansible-doc redhat.satellite.activation_key
Chapter 10. Creating a New Camel XML file Overview Apache Camel stores routes in an XML file that contains a camelContext element. When you create a new Fuse Integration project, the tooling provides an Apache Camel context (XML) file as part of the project by default. You can also add a new Camel XML file that includes all of the required namespaces preconfigured and a template camelContext element. Procedure To add a new Apache Camel context file to your project: Select File New Camel XML File from the main menu to open the Camel XML File wizard, as shown in Figure 10.1, "Camel XML File wizard" . Figure 10.1. Camel XML File wizard In RouteContainer , enter the location for the new file, or accept the default. You can click to search for an appropriate location. Important The Spring framework and the OSGi Blueprint framework require that all Apache Camel files be placed in specific locations under the project's META-INF or OSGI-INF folder: Spring - projectName/src/main/resources/META-INF/spring/ OSGi Blueprint - projectName/src/main/resources/OSGI-INF/blueprint/ In File Name , enter a name for the new context file, or accept the default ( camelContext.xml ). The file's name cannot contain spaces or special characters, and it must be unique within the JVM. In Framework , accept the default, or select which framework the routes will use: Spring - [default] for routes that will be deployed in Spring containers, non-OSGi containers, or as standalone applications OSGi Blueprint - for routes that will be deployed in OSGi containers Routes - for routes that you can load and add into existing camelContext s Click Finish . The new context file is added to the project and opened in the route editor.

Commands:
10.4. XML Representation of a Cluster Example 10.1. An XML representation of a cluster

Commands:
<cluster id="00000000-0000-0000-0000-000000000000" href="/ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000"> <name>Default</name> <description>The default server cluster</description> <link rel="networks" href="/ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000/networks"/> <link rel="permissions" href="/ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000/permissions"/> <link rel="glustervolumes" href="/ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000/glustervolumes"/> <link rel="glusterhooks" href="/ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000/glusterhooks"/> <link rel="affinitygroups" href="/ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000/affinitygroups"/> <cpu id="Intel Penryn Family"/> <architecture>X86_64<architecture/> <data_center id="00000000-0000-0000-0000-000000000000" href="/ovirt-engine/api/datacenters/00000000-0000-0000-0000-000000000000"/> <memory_policy> <overcommit percent="100"/> <transparent_hugepages> <enabled>false</enabled> </transparent_hugepages> </memory_policy> <scheduling_policies> <policy>evenly_distributed</policy> <thresholds low="10" high="75" duration="120"/> </scheduling_policies> <version major="4" minor="0"/> <supported_versions> <version major="4" minor="0"/> </supported_versions> <error_handling> <on_error>migrate</on_error> </error_handling> <virt_service>true</virt_service> <gluster_service>false</gluster_service> <threads_as_cores>false</threads_as_cores> <tunnel_migration>false</tunnel_migration> <trusted_service>false</trusted_service> <ha_reservation>false</ha_reservation> <ballooning_enabled>false</ballooning_enabled> <ksm> <enabled>true</enabled> </ksm> </cluster>
Chapter 5. Cloud The following chapters contain the most notable changes to public cloud platforms between RHEL 8 and RHEL 9: 5.1. Notable changes to Azure TDX support is available a Technology Preview for RHEL on Azure The Intel Trust Domain Extension (TDX) feature can as a Technology Preview now be used in RHEL 9.4 guest operating systems. If the host system supports TDX, you can deploy hardware-isolated RHEL 9 virtual machines (VMs), called trust domains (TDs). As a result, you will be able to create a CVM image with SecureBoot enabled on the Azure platform. 5.2. Notable changes to GCP TDX support is available a Technology Preview for RHEL on GCP The Intel Trust Domain Extension (TDX) feature can as a Technology Preview now be used in RHEL 9.4 guest operating systems. If the host system supports TDX, you can deploy hardware-isolated RHEL 9 virtual machines (VMs), called trust domains (TDs). With this enhancement, you can use the Intel Trust Domain Extension (TDX) feature in RHEL 9.4 on Google Cloud Platform.

Commands:
Chapter 4. Distribution of content RHEL 8 for SAP Solutions is installed using ISO images. For more information, see Installing RHEL 8 for SAP Solutions . For information on RHEL for SAP Solutions offerings on Certified Cloud Providers, see SAP Offerings on Certified Cloud Providers . Installation Steps for Red Hat Enterprise Linux for SAP Solutions After downloading, perform your installation of Red Hat Enterprise Linux . Register and attach your server to a repository source - either a local Red Hat Satellite instance or the Customer Portal Subscription Management service. Apply the release lock and activate the SAP repositories in the Red Hat subscription manager to get access to the additional packages provided by the Red Hat Enterprise Linux for SAP Solutions subscription. Execute the Red Hat Enterprise Linux system roles for SAP to automatically perform all required OS preconfiguration tasks to get started with the SAP workload installation afterwards. When your Red Hat Enterprise Linux for SAP Solutions system is ready, you can start your SAP installation , for example SAP HANA Express Edition. Get predictive IT analytics with connecting your system to Red Hat Insights. This is included with your subscription. If you need help installing your product, contact Red Hat Customer Service or Technical Support . SAP specific content is available on separate SAP repositories and ISOs and only for SAP-supported architectures (Intel x86_64, IBM Power LE). See How to subscribe SAP HANA systems to the Update Services for SAP Solutions . Additional resources Performing a standard RHEL installation Package manifest Considerations in adopting RHEL 8

Commands:
4.2. Expiration Operations Expiration in Red Hat JBoss Data Grid allows you to set a life span or maximum idle time value for each key/value pair stored in the cache. The life span or maximum idle time can be set to apply cache-wide or defined for each key/value pair using the cache API. The life span ( lifespan ) or maximum idle time ( maxIdle in Library Mode and max-idle in Remote Client-Server Mode) defined for an individual key/value pair overrides the cache-wide default for the entry in question. Report a bug

Commands:
8.11. busybox 8.11.1. RHSA-2013:1732 - Low: busybox security and bug fix update Updated busybox packages that fix one security issue and several bugs are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having low security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link associated with the description below. BusyBox provides a single binary that includes versions of a large number of system commands, including a shell. This can be very useful for recovering from certain types of system failures, particularly those involving broken shared libraries. Security Fix CVE-2013-1813 It was found that the mdev BusyBox utility could create certain directories within /dev with world-writable permissions. A local unprivileged user could use this flaw to manipulate portions of the /dev directory tree. Bug Fixes BZ# 820097 Previously, due to a too eager string size optimization on the IBM System z architecture, the "wc" BusyBox command failed after processing standard input with the following error: wc: : No such file or directory This bug was fixed by disabling the string size optimization and the "wc" command works properly on IBM System z architectures. BZ# 859817 Prior to this update, the "mknod" command was unable to create device nodes with a major or minor number larger than 255. Consequently, the kdump utility failed to handle such a device. The underlying source code has been modified, and it is now possible to use the "mknod" command to create device nodes with a major or minor number larger than 255. BZ# 855832 If a network installation from an NFS server was selected, the "mount" command used the UDP protocol by default. If only TCP mounts were supported by the server, this led to a failure of the mount command. As a result, Anaconda could not continue with the installation. This bug is now fixed and NFS mount operations default to the TCP protocol. All busybox users are advised to upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
10.6. Methods 10.6.1. Creating a Cluster Creation of a new cluster requires the name , cpu id= and datacenter elements. Identify the datacenter with either the id attribute or name element. Example 10.3. Creating a cluster 10.6.2. Updating a Cluster The name , description , cpu id= and error_handling elements are updatable post-creation. Example 10.4. Updating a cluster 10.6.3. Removing a Cluster Removal of a cluster requires a DELETE request. Example 10.5. Removing a cluster

Commands:
POST /ovirt-engine/api/clusters HTTP/1.1 Accept: application/xml Content-type: application/xml <cluster> <name>cluster1</name> <cpu id="Intel Penryn Family"/> <data_center id="00000000-0000-0000-0000-000000000000"/> </cluster>
PUT /ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000 HTTP/1.1 Accept: application/xml Content-type: application/xml <cluster> <description>Cluster 1</description> </cluster>
DELETE /ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000 HTTP/1.1 HTTP/1.1 204 No Content