mtpti5iD/redhat-docs_dataset huggingface dataset:
5.47. dbus 5.47.1. RHSA-2012:1261 - Moderate: dbus security update Updated dbus 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 moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. D-Bus is a system for sending messages between applications. It is used for the system-wide message bus service and as a per-user-login-session messaging facility. Security Fix CVE-2012-3524 It was discovered that the D-Bus library honored environment settings even when running with elevated privileges. A local attacker could possibly use this flaw to escalate their privileges, by setting specific environment variables before running a setuid or setgid application linked against the D-Bus library (libdbus). Note: With this update, libdbus ignores environment variables when used by setuid or setgid applications. The environment is not ignored when an application gains privileges via file system capabilities; however, no application shipped in Red Hat Enterprise Linux 6 gains privileges via file system capabilities. Red Hat would like to thank Sebastian Krahmer of the SUSE Security Team for reporting this issue. All users are advised to upgrade to these updated packages, which contain a backported patch to correct this issue. For the update to take effect, all running instances of dbus-daemon and all running applications using the libdbus library must be restarted, or the system rebooted.

Commands:
21.7. virt-df: Monitoring Disk Usage This section provides information about monitoring disk usage. 21.7.1. Introduction This section describes virt-df , which displays file system usage from a disk image or a guest virtual machine. It is similar to the Linux df command, but for virtual machines. 21.7.2. Running virt-df To display file system usage for all file systems found in a disk image, enter the following: (Where /dev/vg_guests/RHEL7 is a Red Hat Enterprise Linux 7 guest virtual machine disk image. The path in this case is the host physical machine logical volume where this disk image is located.) You can also use virt-df on its own to list information about all of your guest virtual machines known to libvirt. The virt-df command recognizes some of the same options as the standard df such as -h (human-readable) and -i (show inodes instead of blocks). Note You can use virt-df safely on live guest virtual machines, since it only needs read-only access. However, you should not expect the numbers to be precisely the same as those from a df command running inside the guest virtual machine. This is because what is on disk will be slightly out of sync with the state of the live guest virtual machine. Nevertheless it should be a good enough approximation for analysis and monitoring purposes. virt-df is designed to allow you to integrate the statistics into monitoring tools, databases and so on. This allows system administrators to generate reports on trends in disk usage, and alerts if a guest virtual machine is about to run out of disk space. To do this you should use the --csv option to generate machine-readable Comma-Separated-Values (CSV) output. CSV output is readable by most databases, spreadsheet software and a variety of other tools and programming languages. The raw CSV looks like the following:

Commands:
virt-df -a /dev/vg_guests/RHEL7 Filesystem 1K-blocks Used Available Use% RHEL6:/dev/sda1 101086 10233 85634 11% RHEL6:/dev/VolGroup00/LogVol00 7127864 2272744 4493036 32%
virt-df -h -d domname Filesystem Size Used Available Use% F14x64:/dev/sda1 484.2M 66.3M 392.9M 14% F14x64:/dev/vg_f14x64/lv_root 7.4G 3.0G 4.4G 41% RHEL6brewx64:/dev/sda1 484.2M 52.6M 406.6M 11% RHEL6brewx64:/dev/vg_rhel6brewx64/lv_root 13.3G 3.4G 9.2G 26%
virt-df --csv -d RHEL6Guest Virtual Machine,Filesystem,1K-blocks,Used,Available,Use% RHEL6brewx64,/dev/sda1,102396,24712,77684,24.1% RHEL6brewx64,/dev/sda2,20866940,7786652,13080288,37.3%
Chapter 6. Senders and receivers The client uses sender and receiver links to represent channels for delivering messages. Senders and receivers are unidirectional, with a source end for the message origin, and a target end for the message destination. Sources and targets often point to queues or topics on a message broker. Sources are also used to represent subscriptions. 6.1. Creating queues and topics on demand Some message servers support on-demand creation of queues and topics. When a sender or receiver is attached, the server uses the sender target address or the receiver source address to create a queue or topic with a name matching the address. The message server typically defaults to creating either a queue (for one-to-one message delivery) or a topic (for one-to-many message delivery). The client can indicate which it prefers by setting the queue or topic capability on the source or target. For more details, see the following examples: queue-send.rb queue-receive.rb topic-send.rb topic-receive.rb 6.2. Creating durable subscriptions A durable subscription is a piece of state on the remote server representing a message receiver. Ordinarily, message receivers are discarded when a client closes. However, because durable subscriptions are persistent, clients can detach from them and then re-attach later. Any messages received while detached are available when the client re-attaches. Durable subscriptions are uniquely identified by combining the client container ID and receiver name to form a subscription ID. These must have stable values so that the subscription can be recovered. Example 6.3. Creating shared subscriptions A shared subscription is a piece of state on the remote server representing one or more message receivers. Because it is shared, multiple clients can consume from the same stream of messages. The client configures a shared subscription by setting the shared capability on the receiver source. Shared subscriptions are uniquely identified by combining the client container ID and receiver name to form a subscription ID. These must have stable values so that multiple client processes can locate the same subscription. If the global capability is set in addition to shared , the receiver name alone is used to identify the subscription. Example

Commands:
Chapter 6. Running the certification tests RHCert CLI is the supported method to run tests. Procedure Run tests The non-interactive tag is an RHCert flag used to run all certification-related mandatory tests. Save the test result file By default, the result file is saved as /var/rhcert/save/rhcert-results-<host-name>-<timestamp>.xml .

Commands:
rhcert run
rhcert-save
Chapter 4. Deploying Red Hat Quay on premise The following image shows examples for on premise configuration, for the following types of deployments: Standalone Proof of Concept Highly available deployment on multiple hosts Deployment on an OpenShift Container Platform cluster by using the Red Hat Quay Operator On premise example configurations 4.1. Red Hat Quay example deployments The following image shows three possible deployments for Red Hat Quay: Deployment examples Proof of Concept Running Red Hat Quay, Clair, and mirroring on a single node, with local image storage and local database Single data center Running highly available Red Hat Quay, Clair ,and mirroring, on multiple nodes, with HA database and image storage Multiple data centers Running highly available Red Hat Quay, Clair, and mirroring, on multiple nodes in multiple data centers, with HA database and image storage 4.2. Red Hat Quay deployment topology The following image provides a high level overview of a Red Hat Quay deployment topology: Red Hat Quay deployment topology In this deployment, all pushes, user interface, and API requests are received by public Red Hat Quay endpoints. Pulls are served directly from object storage . 4.3. Red Hat Quay deployment topology with storage proxy The following image provides a high level overview of a Red Hat Quay deployment topology with storage proxy configured: Red Hat Quay deployment topology with storage proxy With storage proxy configured, all traffic passes through the public Red Hat Quay endpoint.

Commands:
Chapter 4. Upgrading Red Hat JBoss Web Server using this Service Pack To install this service pack: Go to the Software Downloads page for Red Hat JBoss Web Server 6.0 . Note You require a Red Hat subscription to access the Software Downloads page. Download the Red Hat JBoss Web Server 6.0 Service Pack 5 archive file that is appropriate to your platform. Extract the archive file to the Red Hat JBoss Web Server installation directory. If you have installed Red Hat JBoss Web Server from RPM packages on Red Hat Enterprise Linux, you can use the following yum command to upgrade to the latest service pack: Note Red Hat distributes the JBoss Web Server 6.0 Service Pack 5 release in RPM packages only.

Commands:
yum upgrade
4.5. REDUNDANCY The REDUNDANCY panel allows you to configure the backup LVS router node and set various heartbeat monitoring options. Note The first time you visit this screen, it displays an "inactive" Backup status and an ENABLE button. To configure the backup LVS router, click on the ENABLE button so that the screen matches Figure 4.4, "The REDUNDANCY Panel" . Figure 4.4. The REDUNDANCY Panel Redundant server public IP Enter the public real IP address for the backup LVS router node. Redundant server private IP Enter the backup node's private real IP address in this text field. If you do not see the field called Redundant server private IP , go back to the GLOBAL SETTINGS panel and enter a Primary server private IP address and click ACCEPT . The section of the panel is devoted to configuring the heartbeat channel, which is used by the backup node to monitor the primary node for failure. Heartbeat Interval (seconds) This field sets the number of seconds between heartbeats - the interval that the backup node will check the functional status of the primary LVS node. Assume dead after (seconds) If the primary LVS node does not respond after this number of seconds, then the backup LVS router node will initiate failover. Heartbeat runs on port This field sets the port at which the heartbeat communicates with the primary LVS node. The default is set to 539 if this field is left blank. The final section of the panel is for enabling and configuration of the optional Synchronization Daemon and its various options. The Sync Daemon enables the active and backup LVS director to keep TCP state synchronized. When enabled, the active director will send a message multicast over the network with a configurable synchronization ID (or syncid) to a receiving backup director. Warning Red Hat Enterprise Linux 6.5 introduces a new sync message protocol format designed to prevent interruptions to business services caused by premature timeout of persistent connections on backup nodes, causing inconsistent state in the event of failover. The new protocol format is not compatible with versions of Red Hat Enterprise Linux 6.4 or earlier, or kernel versions prior to kernel-2.6.32-406.el6. It is recommended to upgrade backup nodes before upgrading the master node to Red Hat Enterprise Linux 6.5. To continue using the old format for sync messages (for example if you need to upgrade the master node prior to the backup nodes), then set the value of sync_version using the echo command as root at a shell prompt as follows: Use Sync Daemon Check the box if you want to enable the Sync Daemon. Sync Daemon Interface The network interface through which the sync daemon will send/receive its multicast message. The default interface in this field is eth0 . Sync daemon id This field sets an identifier (ID) to multicast sync messages. Supported values are 0 to 255, with the default being 0 if the field is left blank. Warning Remember to click the ACCEPT button after making any changes in this panel to make sure you do not lose any changes when selecting a new panel.

Commands:
echo 0 > /proc/sys/net/ipv4/vs/sync_version
Chapter 12. Updating and downgrading IdM 12.1. Updating IdM packages You can use the yum utility to update the Identity Management (IdM) packages on the system. Prerequisites Ensure you have applied all previously released errata relevant to the RHEL system. For more information, see the How do I apply package updates to my RHEL system? KCS article. Procedure Select one of the following options: To update all IdM packages that are relevant for your profile and that have updates available: To install or update packages to match the latest version available for your profile from any enabled repository: After you update the IdM packages on at least one server, all other servers in the topology receive the updated schema, even if you do not update their packages. This ensures that any new entries which use the new schema can be replicated among the other servers. Warning When updating multiple IdM servers, wait at least 10 minutes after updating one server before updating another server. However, the actual time required for a server's successful update depends on the topology deployed, the latency of the connections, and the number of changes generated by the update. When two or more servers are updated simultaneously or with only short intervals between the upgrades, there is not enough time to replicate the post-upgrade data changes throughout the topology, which can result in conflicting replication events. Important Upgrade to the version only. For example, if you want to upgrade to IdM for RHEL 8.8, upgrade from IdM for RHEL 8.7. Upgrading from earlier versions can cause problems. Additional resources yum(8) man page on your system 12.2. Downgrading IdM packages Red Hat does not support downgrading Identity Management.

Commands:
yum upgrade ipa- *
yum distro-sync ipa- *
4.186. nautilus 4.186.1. RHBA-2011:1203 - nautilus bug fix update Updated nautilus packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The Nautilus file manager is a core component of the GNOME desktop project. It allows users to browse directories on local and remote file systems, preview files and launch applications associated with them. It is also responsible for handling the icons on the GNOME desktop. Bug Fixes BZ# 616774 Previously, the "Volume is busy" dialog was not linked to any window, which led to the "Untitled window" item appearing on the taskbar when the user unmounted or ejected a device with one or more files opened. This update sets the dialog temporarily for the desktop window which automatically removes the taskbar item. BZ# 636881 Previously, an incorrect signal was emitted when the user changed the name of a bookmark created in Nautilus. As a consequence, the changes got lost and the new name was not written into the bookmark file. This has been fixed: the correct signal is now emitted and the bookmarks can be properly updated. BZ# 652607 Previously, Nautilus could close unexpectedly with a segmentation fault due to a race condition if the user selected a file that was already deleted but was still displayed in the window. This has been fixed and Nautilus does not terminate unexpectedly any longer. BZ# 654091 Previously, the GNOME Configuration (GConf) schemas were missing. As a consequence, the position and size of the folder windows were lost once the user closed the window. The missing GConf schemas have been added and the position and size of the folder windows are now saved and restored correctly. BZ# 661589 Prior to this update, Nautilus did not reflect the changes made to the locations of the XDG (Base Directory Specification) file system directories and used the old locations instead. As a consequence, files created on the desktop may have disappeared if the user logged on used a different user interface language. This problem has been fixed: the desktop is now refreshed with every change of the XDG directories. BZ# 666086 Previously, Nautilus could have become suspended when the user copied files from an FTP server. This was caused by an error in the GVFS (GNOME virtual file system) client dbus code which prevented recursive synchronous calls. This has been fixed and Nautilus no longer becomes suspended during the file transfers. BZ# 690147 Prior to this update, Nautilus did not refresh the folder buttons in the path bar when deleting the linked directories. When clicking on the folder icon in the path bar, an error message appeared. Now, folder buttons in the path bar are automatically removed when deleting the linked directory. All users of nautilus are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 13. Preparing for upgrading with external Ceph deployments If you are upgrading with external Ceph deployments, you must complete the procedures included in this section. Note If your deployment does not use an external Ceph Storage cluster, you must skip the procedures included in this section and continue to the section. 13.1. Installing ceph-ansible If you are upgrading with external Ceph deployments, you must complete this procedure. The ceph-ansible package is required when you use Ceph Storage with Red Hat OpenStack Platform. Procedure Enable the Ceph Tools repository: Install the ceph-ansible package: 13.2. Setting the ceph-ansible repository The Red Hat OpenStack Platform 16.2 validation framework tests that ceph-ansible is installed correctly before director upgrades the overcloud to Red Hat Ceph Storage 4. The framework uses the CephAnsibleRepo parameter to check that you installed ceph-ansible from the correct repository. Director disables the test after you run the openstack overcloud upgrade prepare command and this test remains disabled through the duration of the Red Hat OpenStack Platform 16.2 overcloud upgrade. Director re-enables this test after running the openstack overcloud upgrade converge command. However, to prepare for this validation, you must set the CephAnsibleRepo parameter to the Red Hat Ceph Storage Tools 4 for RHEL 8 repository. Procedure Log in to the undercloud as the stack user. Edit the environment file that contains your overcloud Ceph Storage configuration. This file is usually named ceph-config.yaml and you can find it in your templates directory: Add the CephAnsibleRepo parameter to the parameter_defaults section: CephAnsibleRepo sets the repository that includes ceph-ansible . The validation framework uses this parameter to check that you have installed ceph-ansible on the undercloud. Save the ceph-config.yaml file.

Commands:
[stack@director ~]USD sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
[stack@director ~]USD sudo dnf install -y ceph-ansible
vi /home/stack/templates/ceph-config.yaml
parameter_defaults: CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
Chapter 10. General Configuration 10.1. JBoss Data Virtualization Settings The following types of JBoss Data Virtualization settings are available for viewing and modification: Buffer service settings Cache settings (including result set and prepared plan cache settings) Runtime engine deployer settings Authorization validator and policy decider settings Transport and SSL settings Translator settings To view all of the available settings for JBoss Data Virtualization, run the following command within the Management CLI: Note To look further into translator and transport (including SSL) settings see Section 10.4, "Managing Transport and SSL Settings Using Management CLI" and Section 10.5, "Managing Translator Settings Using Management CLI" .

Commands:
/subsystem=teiid:read-resource-description
Chapter 1. Introduction to InfiniBand and RDMA InfiniBand refers to two distinct things: The physical link-layer protocol for InfiniBand networks The InfiniBand Verbs API, an implementation of the remote direct memory access (RDMA) technology RDMA provides access between the main memory of two computers without involving an operating system, cache, or storage. By using RDMA, data transfers with high-throughput, low-latency, and low CPU utilization. In a typical IP data transfer, when an application on one machine sends data to an application on another machine, the following actions happen on the receiving end: The kernel must receive the data. The kernel must determine that the data belongs to the application. The kernel wakes up the application. The kernel waits for the application to perform a system call into the kernel. The application copies the data from the internal memory space of the kernel into the buffer provided by the application. This process means that most network traffic is copied across the main memory of the system if the host adapter uses direct memory access (DMA) or otherwise at least twice. Additionally, the computer executes some context switches to switch between the kernel and application. These context switches can cause a higher CPU load with high traffic rates while slowing down the other tasks. Unlike traditional IP communication, RDMA communication bypasses the kernel intervention in the communication process. This reduces the CPU overhead. After a packet enters a network, the RDMA protocol enables the host adapter to decide which application should receive it and where to store it in the memory space of that application. Instead of sending the packet for processing to the kernel and copying it into the memory of the user application, the host adapter directly places the packet contents in the application buffer. This process requires a separate API, the InfiniBand Verbs API, and applications need to implement the InfiniBand Verbs API to use RDMA. Red Hat Enterprise Linux supports both the InfiniBand hardware and the InfiniBand Verbs API. Additionally, it supports the following technologies to use the InfiniBand Verbs API on non-InfiniBand hardware: iWARP: A network protocol that implements RDMA over IP networks RDMA over Converged Ethernet (RoCE), which is also known as InfiniBand over Ethernet (IBoE): A network protocol that implements RDMA over Ethernet networks

Commands:
4.256. Qpid 4.256.1. RHEA-2012:0530 - Qpid bug fix and enhancement update Updated Qpid packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Apache Qpid is a reliable, cross-platform, asynchronous messaging system that supports the Advanced Message Queuing Protocol (AMQP) in several common programming languages. The qpid-cpp packages provide a message broker daemon that receives, stores and routes messages using the open AMQP messaging protocol along with run-time libraries for AMQP client applications developed using Qpid C++. Clients exchange messages with an AMQP message broker using the AMQP protocol. The qpid-qmf packages provide an extensible management framework layered on Qpid messaging. The qpid-tools package provides management and diagnostic tools for Apache Qpid brokers and clients. The qpid-tests package contains conformance tests for Apache Qpid. The python-qpid package provides a python client library for the Apache Qpid implementation of the AMQP protocol. The qpid-cpp, qpid-qmf, qpid-tools, qpid-tests and python-qpid packages have been upgraded to upstream version 0.14, which provide a number of bug fixes and enhancements over the version. (BZ# 807935 , BZ# 807936 , BZ# 807943 , BZ# 807946 , BZ# 807948 ) All users of Qpid are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands: