mtpti5iD/redhat-docs_dataset huggingface dataset:
9.3.2. Domain Processes As provided in Red Hat Enterprise Linux, libvirt uses libnuma to set memory binding policies for domain processes. The nodeset for these policies can be configured either as static (specified in the domain XML) or auto (configured by querying numad). Refer to the following XML configuration for examples on how to configure these inside the <numatune> tag: <numatune> <memory mode='strict' placement=' auto '/> </numatune> <numatune> <memory mode='strict' nodeset=' 0,2-3 '/> </numatune> libvirt uses sched_setaffinity(2) to set CPU binding policies for domain processes. The cpuset option can either be static (specified in the domain XML) or auto (configured by querying numad). Refer to the following XML configuration for examples on how to configure these inside the <vcpu> tag: <vcpu placement=' auto ' current='8'>32</vcpu> <vcpu placement=' static ' cpuset='0-10,^5'>8</vcpu> There are implicit inheritance rules between the placement mode you use for <vcpu> and <numatune>: The placement mode for <numatune> defaults to the same placement mode of <vcpu>, or to static if a <nodeset> is specified. Similarly, the placement mode for <vcpu> defaults to the same placement mode of <numatune>, or to static if <cpuset> is specified. This means that CPU tuning and memory tuning for domain processes can be specified and defined separately, but they can also be configured to be dependent on the other's placement mode. Note Refer to the following URLs for more information on vcpu and numatune: http://libvirt.org/formatdomain.html#elementsCPUAllocation and http://libvirt.org/formatdomain.html#elementsNUMATuning

Commands:
<numatune> <memory mode='strict' placement=' auto '/> </numatune>
<numatune> <memory mode='strict' nodeset=' 0,2-3 '/> </numatune>
<vcpu placement=' auto ' current='8'>32</vcpu>
<vcpu placement=' static ' cpuset='0-10,^5'>8</vcpu>
8.199. rgmanager 8.199.1. RHBA-2014:1586 - rgmanager bug fix and enhancement update Updated rgmanager packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The rgmanager packages contain the Red Hat Resource Group Manager, which is used to create and manage high-availability server applications in the event of system downtime. Bug Fixes BZ# 952729 When moving services around a cluster, it was not possible to refer to virtual machines without the "vm:" prefix. With this update, the virtual machines can be controlled both with and without the "vm:" prefix. BZ# 1812079 When a custom resource agent was configured without the primary attribute, the rgmanager utility terminated unexpectedly with a segmentation fault. The underlying source code has been modified to address this bug, and an error is logged instead of the crash of rgmanager in the described scenario. BZ# 1033162 Previously, the rg_test utility did not handle exit codes correctly; when rg_test failed, the zero exit code was returned instead of a non-zero exit code. This update applies a patch to fix this bug and if rg_test crashes, the zero exit code is returned as expected. BZ# 1036652 When the "time_t" values were not configured correctly in the cluster.conf file, the rgmanager could terminate unexpectedly. This update provides a patch to fix this bug, and rgmanager now properly handles the incorrectly configured values. BZ# 1053739 When more instances were configured for a resource address than were specified with the "maxinstances" attribute, no message was logged. With this update, a warning is returned in such a case. In addition, this update adds the following Enhancement BZ# 982820 When a resource start or status operation failed to execute due to resource starvation on the node, the user had to reboot the node manually. With this enhancement, a new reboot_on_pid_exhaustion flag has been added. The flag allows to set up rgmanager to reboot the node automatically in the described scenario. Users of rgmanager are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 1. Migrating your data Use Red Hat JBoss Data Virtualization's backup and restore functionality to migrate the data stored in your hierarchical database. Each backup you create will contain all of the content for all of the workspaces in a single repository. Therefore, you will need to back up and restore each of your repositories one by one. The backup and restore functionality is provided by the org.modeshape.jcr.api.RepositoryManager interface: Run this code in an Apache Jackrabbit (JCR) session in any workspace to access the repository manager: 1.1. Back up your repository Use the backupRepository method provided by the org.modeshape.jcr.api.RepositoryManager interface to back up your repository. All of the workspaces that existed when the back up was initiated will be saved. If you call the backup method on a repository that is in use, all of the changes made while the backup process is underway are also saved. Note The method blocks other calls until the backup is completed, so you must invoke the method asynchronously to avoid disruptions. Each backup is stored on the file system in a series of Gzip archives. A sub-directory for storing large binaries is also created. To back up your repository, run this code in your Apache JCR session: Note You must initiate each operation. There is no way to automatically schedule a backup.

Commands:
public interface RepositoryManager { Problems backupRepository( File backupDirectory ) throws RepositoryException; Problems restoreRepository( File backupDirectory ) throws RepositoryException; }
javax.jcr.Repository repository = javax.jcr.Credentials credentials = String workspaceName = javax.jcr.Session session = repository.login(credentials,workspaceName); org.modeshape.jcr.api.Session msSession = (org.modeshape.jcr.api.Session)session; org.modeshape.jcr.api.RepositoryManager repoMgr = ((org.modeshape.jcr.api.Session)session).getWorkspace().getRepositoryManager();
org.modeshape.jcr.api.RepositoryManager repoMgr = java.io.File backupDirectory = Problems problems = repoMgr.backupRepository(backupDirectory); if ( problems.hasProblems() ) { System.out.println("Problems restoring the repository:"); // Report the problems (we'll just print them out) for ( Problem problem : problems ) { System.out.println(problem); } } else { System.out.println("The backup was successful"); }
4. General Updates Intel Xeon support in OProfile OProfile is a system-wide Linux profiler, capable of running at low overhead. It consists of a kernel driver and a daemon for collecting raw sample data, along with a suite of tools for parsing that data into meaningful information. OProfile is generally used by developers to determine which sections of code consume the most amount of CPU time, and why. OProfile in Red Hat Enterprise Linux 4.9 now supports Intel Xeon (formerly codenamed Nehalem) processor performance events. Improved Checksum support in coreutils Newer Red Hat disk images use the SHA-256 algorithm as the checksum method. Previously, verifying these checksums on Red Hat Enterprise Linux 4 was not a simple process. Red Hat Enterprise Linux 4.9 provides an updated coreutils package, containing checksum utilities for the whole SHA-2 family, allowing a user to easily count or verify SHA-224, SHA-256, SHA-384, and SHA-512 checksums. KornShell KSH-93 is the most recent version of the KornShell ( ksh ) by David Korn of AT&T Bell Laboratories, a shell programming language upwards-compatible with sh (the Bourne Shell). In Red Hat Enterprise Linux 4.9, ksh is updated to the upstream release version ksh93t+ . Firefox Red Hat Enterprise Linux 4.9 features version 3.6.13 of the Mozilla Firefox open source web browser. Refer to the Firefox 3.6 Release Notes and Firefox 3.6.13 Release Notes for further details on the bug fixes and enhancements provided by this update. SystemTap SystemTap is a tracing and probing tool that allows users to study and monitor the activities of the operating system (particularly, the kernel) in fine detail. It provides information similar to the output of tools like netstat, ps, top, and iostat; however, SystemTap is designed to provide more filtering and analysis options for collected information. SystemTap in Red Hat Enterprise Linux 4.9 has been updated to version 1.3. Most notably, this update provides support for the newer kprobe capabilities.

Commands:
Chapter 3. Core Infrastructure and Mechanics Important To use the cpupower command featured in this chapter, ensure you have the kernel-tools package installed. 3.1. CPU Idle States CPUs with the x86 architecture support various states in which parts of the CPU are deactivated or run at lower performance settings. These states, known as C-states , allow systems to save power by partially deactivating CPUs that are not in use. C-states are numbered from C0 upwards, with higher numbers representing decreased CPU functionality and greater power saving. C-States of a given number are broadly similar across processors, although the exact details of the specific feature sets of the state may vary between processor families. C-States 0-3 are defined as follows: C0 the operating or running state. In this state, the CPU is working and not idle at all. C1, Halt a state where the processor is not executing any instructions but is typically not in a lower power state. The CPU can continue processing with practically no delay. All processors offering C-States need to support this state. Pentium 4 processors support an enhanced C1 state called C1E that actually is a state for lower power consumption. C2, Stop-Clock a state where the clock is frozen for this processor but it keeps the complete state for its registers and caches, so after starting the clock again it can immediately start processing again. This is an optional state. C3, Sleep a state where the processor really goes to sleep and does not need to keep its cache up to date. Waking up from this state takes considerably longer than from C2 due to this. Again this is an optional state. To view available idle states and other statistics for the CPUidle driver, enter: Recent Intel CPUs with the "Nehalem" microarchitecture feature a new C-State, C6, which can reduce the voltage supply of a CPU to zero, but typically reduces power consumption by between 80% and 90%. The kernel in Red Hat Enterprise Linux 7 includes optimizations for this new C-State.

Commands:
~]USD cpupower idle-info
Chapter 1. HTTP connectors Red Hat JBoss Core Services (JBCS) includes two different HTTP connectors that the Apache HTTP Server can use to load-balance HTTP requests to a set of back-end servlet containers: The Apache Tomcat connector ( mod_jk ) supports the load balancing of HTTP requests to a set of servlet containers, while maintaining sticky sessions and communicating over the Apache JServ Protocol (AJP). The JBoss HTTP connector ( mod_proxy_cluster ) is a more advanced load balancer than mod_jk . The mod_proxy_cluster connector provides all the functionality of mod_jk and additional features such as real-time load-balancing calculations, application life-cycle control, automatic proxy discovery, and multiple protocol support. JBCS and Red Hat Enterprise Linux (RHEL) provide separate distributions of the Apache HTTP Server. You can use the JBCS distribution of the Apache HTTP Server to connect to back-end application servers by using the mod_jk , mod_proxy_cluster , or mod_proxy connector as a proxy. Consider the following guidelines: From RHEL 7 onward, the JBCS and RHEL distributions of the Apache HTTP Server provide identical mod_proxy modules. On RHEL versions 7 and 8, only the JBCS distribution of the Apache HTTP Server provides the mod_jk and mod_proxy_cluster connectors. From RHEL 9 onward, the JBCS and RHEL distributions of the Apache HTTP Server also provide identical copies of the mod_jk connector and the mod_proxy_cluster connector. Installing a JBCS distribution of the Apache HTTP Server from an archive file or from RPM packages by using the groupinstall option also automatically installs the mod_jk and mod_proxy_cluster connectors. Installing the RHEL 9 distribution of the Apache HTTP Server does not automatically install the mod_jk and mod_proxy_cluster connectors. In this situation, you can manually install the appropriate mod_jk or mod_proxy_cluster package by using RHEL Application Streams. For more information, see Mod_jk installation and Mod_proxy_cluster installation and upgrade . The Apache HTTP Server Connectors and Load Balancing Guide describes how to install and configure the mod_jk and mod_proxy_cluster connectors that JBCS provides. This guide also includes a working example for basic load-balancing with mod_proxy_cluster . Important Most file and directory paths shown in this guide are for an archive installation of JBCS on Red Hat Enterprise Linux. For other platforms, use the correct paths for your respective installation, as specified in the Red Hat JBoss Core Services Apache HTTP Server Installation Guide . Additional resources Load balancing with the Apache Tomcat connector ( mod_jk ) Load balancing with the JBoss HTTP connector ( mod_proxy_cluster )

Commands:
15.2.2.2. Conflicting Files If you attempt to install a package that contains a file which has already been installed by another package or an earlier version of the same package, the following is displayed: To make RPM ignore this error, use the --replacefiles option:

Commands:
Preparing... ########################################### [100%] file /usr/bin/foo from install of foo-1.0-1 conflicts with file from package bar-2.0.20
-ivh --replacefiles foo-1.0-1.i386.rpm
A.2.2. RSA In cryptography, RSA (which stands for Rivest, Shamir and Adleman who first publicly described it) is an algorithm for public-key cryptography. It is the first algorithm known to be suitable for signing as well as encryption, and was one of the first great advances in public key cryptography. RSA is widely used in electronic commerce protocols, and is believed to be secure given sufficiently long keys and the use of up-to-date implementations.

Commands:
2.2. SELinux Contexts for Processes Use the ps -eZ command to view the SELinux context for processes. For example: Procedure 2.2. View the SELinux Context for the passwd Utility Open a terminal, such as Applications System Tools Terminal . Run the passwd utility. Do not enter a new password: Open a new tab, or another terminal, and enter the following command. The output is similar to the following: In the first tab/terminal, press Ctrl+C to cancel the passwd utility. In this example, when the passwd utility (labeled with the passwd_exec_t type) is executed, the user's shell process transitions to the passwd_t domain. Remember that the type defines a domain for processes, and a type for files. To view the SELinux contexts for all running processes, run the ps utility again. Note that below is a truncated example of the output, and may differ on your system: The system_r role is used for system processes, such as daemons. Type Enforcement then separates each domain.

Commands:
~]USD passwd Changing password for user user_name . Changing password for user_name . (current) UNIX password:
~]USD ps -eZ | grep passwd unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 13212 pts/1 00:00:00 passwd
]USD ps -eZ system_u:system_r:dhcpc_t:s0 1869 ? 00:00:00 dhclient system_u:system_r:sshd_t:s0-s0:c0.c1023 1882 ? 00:00:00 sshd system_u:system_r:gpm_t:s0 1964 ? 00:00:00 gpm system_u:system_r:crond_t:s0-s0:c0.c1023 1973 ? 00:00:00 crond system_u:system_r:kerneloops_t:s0 1983 ? 00:00:05 kerneloops system_u:system_r:crond_t:s0-s0:c0.c1023 1991 ? 00:00:00 atd
7.2. Distribution Mode's Consistent Hash Algorithm The hashing algorithm in Red Hat JBoss Data Grid is based on consistent hashing. The term consistent hashing is still used for this implementation, despite some divergence from a traditional consistent hash. Distribution mode uses a consistent hash algorithm to select a node from the cluster to store entries upon. The consistent hash algorithm is configured with the number of copies of each cache entry to be maintained within the cluster. Unlike generic consistent hashing, the implementation used in JBoss Data Grid splits the key space into fixed segments. The number of segments is configurable using numSegments and cannot be changed without restarting the cluster. The mapping of keys to segments is also fixed - a key maps to the same segment, regardless of how the topology of the cluster changes. The number of copies set for each data item requires balancing performance and fault tolerance. Creating too many copies of the entry can impair performance and too few copies can result in data loss in case of node failure. Each hash segment is mapped to a list of nodes called owners. The order is important because the first owner (also known as the primary owner) has a special role in many cache operations (for example, locking). The other owners are called backup owners. There is no rule about mapping segments to owners, although the hashing algorithms simultaneously balance the number of segments allocated to each node and minimize the number of segments that have to move after a node joins or leaves the cluster. 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
Preface Red Hat Quay container registry platform provides secure storage, distribution, and governance of containers and cloud-native artifacts on any infrastructure. It is available as a standalone component or as an Operator on OpenShift Container Platform. Red Hat Quay includes the following features and benefits: Granular security management Fast and robust at any scale High velocity CI/CD Automated installation and upates Enterprise authentication and team-based access control OpenShift Container Platform integration Red Hat Quay is regularly released, containing new features, bug fixes, and software updates. To upgrade Red Hat Quay for both standalone and OpenShift Container Platform deployments, see Upgrade Red Hat Quay . Important Red Hat Quay only supports rolling back, or downgrading, to z-stream versions, for example, 3.7.2 3.7.1. Rolling back to y-stream versions (3.7.0 3.6.0) is not supported. This is because Red Hat Quay updates might contain database schema upgrades that are applied when upgrading to a new version of Red Hat Quay. Database schema upgrades are not considered backwards compatible. Downgrading to z-streams is neither recommended nor supported by either Operator based deployments or virtual machine based deployments. Downgrading should only be done in extreme circumstances. The decision to rollback your Red Hat Quay deployment must be made in conjunction with the Red Hat Quay support and development teams. For more information, contact Red Hat Quay support. Documentation for Red Hat Quay is versioned with each release. The latest Red Hat Quay documentation is available from the Red Hat Quay Documentation page. Currently, version 3 is the latest major version. Note Prior to version 2.9.2, Red Hat Quay was called Quay Enterprise. Documentation for 2.9.2 and prior versions are archived on the Product Documentation for Red Hat Quay 2.9 page.

Commands:
Chapter 2. Monitoring architecture Monitoring tools use a client-server model with the client deployed onto the Red Hat OpenStack Platform overcloud nodes. The Rsyslog service provides client-side centralized logging (CL) and the collectd with enabled sensubility plugin provides client-side availability monitoring (AM). 2.1. Centralized logging In your Red Hat OpenStack environment, collecting the logs from all services in one central location simplifies debugging and administration. These logs come from the operating system, such as syslog and audit log files, infrastructure components such as RabbitMQ and MariaDB, and OpenStack services such as Identity, Compute, and others. The centralized logging toolchain consists of the following components: Log Collection Agent (Rsyslog) Data Store (Elasticsearch) API/Presentation Layer (Kibana) Note Red Hat OpenStack Platform director does not deploy the server-side components for centralized logging. Red Hat does not support the server-side components, including the Elasticsearch database and Kibana. 2.2. Availability monitoring With availability monitoring, you have one central place to monitor the high-level functionality of all components across your entire OpenStack environment. The availability monitoring toolchain consists of several components: Monitoring Agent (collectd with enabled sensubility plugin) Monitoring Relay/Proxy (RabbitMQ) Monitoring Controller/Server (Sensu server) API/Presentation Layer (Uchiwa) Note Red Hat OpenStack Platform director does not deploy the server-side components for availability monitoring. Red Hat does not support the server-side components, including Uchiwa, Sensu Server, the Sensu API plus RabbitMQ, and a Redis instance running on a monitoring node. The availability monitoring components and their interactions are laid out in the following diagrams: Note Items shown in blue denote Red Hat-supported components. Figure 2.1. Availability monitoring architecture at a high level Figure 2.2. Single-node deployment for Red Hat OpenStack Platform Figure 2.3. HA deployment for Red Hat OpenStack Platform

Commands:
Chapter 9. Component details The following table shows the component versions for each Streams for Apache Kafka release. Note Components like the operators, console, and proxy only apply to using Streams for Apache Kafka on OpenShift. Streams for Apache Kafka Apache Kafka Strimzi Operators Kafka Bridge Oauth Cruise Control Console Proxy 2.7.0 3.7.0 0.40.0 0.28 0.15.0 2.5.128 0.1 0.5.1 2.6.0 3.6.0 0.38.0 0.27 0.14.0 2.5.128 - - 2.5.1 3.5.0 0.36.0 0.26 0.13.0 2.5.123 - - 2.5.0 3.5.0 0.36.0 0.26 0.13.0 2.5.123 - - 2.4.0 3.4.0 0.34.0 0.25.0 0.12.0 2.5.112 - - 2.3.0 3.3.1 0.32.0 0.22.3 0.11.0 2.5.103 - - 2.2.2 3.2.3 0.29.0 0.21.5 0.10.0 2.5.103 - - 2.2.1 3.2.3 0.29.0 0.21.5 0.10.0 2.5.103 - - 2.2.0 3.2.3 0.29.0 0.21.5 0.10.0 2.5.89 - - 2.1.0 3.1.0 0.28.0 0.21.4 0.10.0 2.5.82 - - 2.0.1 3.0.0 0.26.0 0.20.3 0.9.0 2.5.73 - - 2.0.0 3.0.0 0.26.0 0.20.3 0.9.0 2.5.73 - - 1.8.4 2.8.0 0.24.0 0.20.1 0.8.1 2.5.59 - - 1.8.0 2.8.0 0.24.0 0.20.1 0.8.1 2.5.59 - - 1.7.0 2.7.0 0.22.1 0.19.0 0.7.1 2.5.37 - - 1.6.7 2.6.3 0.20.1 0.19.0 0.6.1 2.5.11 - - 1.6.6 2.6.3 0.20.1 0.19.0 0.6.1 2.5.11 - - 1.6.5 2.6.2 0.20.1 0.19.0 0.6.1 2.5.11 - - 1.6.4 2.6.2 0.20.1 0.19.0 0.6.1 2.5.11 - - 1.6.0 2.6.0 0.20.0 0.19.0 0.6.1 2.5.11 - - 1.5.0 2.5.0 0.18.0 0.16.0 0.5.0 - - - 1.4.1 2.4.0 0.17.0 0.15.2 0.3.0 - - - 1.4.0 2.4.0 0.17.0 0.15.2 0.3.0 - - - 1.3.0 2.3.0 0.14.0 0.14.0 0.1.0 - - - 1.2.0 2.2.1 0.12.1 0.12.2 - - - - 1.1.1 2.1.1 0.11.4 - - - - - 1.1.0 2.1.1 0.11.1 - - - - - 1.0 2.0.0 0.8.1 - - - - - Note Strimzi 0.26.0 contains a Log4j vulnerability. The version included in the product has been updated to depend on versions that do not contain the vulnerability.

Commands: