mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 14. Locking Red Hat JBoss Data Grid provides locking mechanisms to prevent dirty reads (where a transaction reads an outdated value before another transaction has applied changes to it) and non-repeatable reads. Report a bug 14.1. Configure Locking (Remote Client-Server Mode) In Remote Client-Server mode, locking is configured using the locking element within the cache tags (for example, invalidation-cache , distributed-cache , replicated-cache or local-cache ). Note The default isolation mode for the Remote Client-Server mode configuration is READ_COMMITTED . If the isolation attribute is included to explicitly specify an isolation mode, it is ignored, a warning is thrown, and the default value is used instead. The following is a sample procedure of a basic locking configuration for a default cache in Red Hat JBoss Data Grid's Remote Client-Server mode. Procedure 14.1. Configure Locking (Remote Client-Server Mode) The acquire-timeout parameter specifies the number of milliseconds after which lock acquisition will time out. The concurrency-level parameter defines the number of lock stripes used by the LockManager. The striping parameter specifies whether lock striping will be used for the local cache. Report a bug

Commands:
<distributed-cache> <locking acquire-timeout="30000" concurrency-level="1000" striping="false" /> <!-- Additional configuration here --> </distributed-cache>
Chapter 4. MTR 1.2.5 4.1. New features Migration Toolkit for Runtimes (MTR) 1.2.5 has the following new features: New ruleset for MicroProfile metrics replaces old ruleset A new ruleset for MicroProfile (MP) metrics replaces the old ruleset. (WINDUPRULE-1043) New ruleset for MicroProfile OpenTracing replaces the old ruleset A new ruleset for MicroProfile (MP) OpenTracing replaces the old ruleset. (WINDUPRULE-1044) 4.2. Known issues There are no major known issues in this Migration Toolkit for Runtimes (MTR) 1.2.5 release. For a complete list of all known issues, see the list of MTR 1.2.5 known issues in Jira. 4.3. Resolved issues Migration Toolkit for Runtimes (MTR) 1.2.5 resolves the following issues: CVE-2024-25710 commons-compress: Denial of service caused by an infinite loop A loop with an unreachable exit condition, meaning an Infinite Loop, vulnerability, was found in Apache Common Compress. This issue could have led to a denial of service. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. Users are recommended to upgrade to MTR 1.2.5, which resolves this issue. For more details, see (CVE-2024-25710) . CVE-2024-26308 commons-compress: OutOfMemoryError An allocation of resources without limits or throttling vulnerability was found in Apache Commons Compress. This issue could lead to an out-of-memory error (OOM). This issue affects Apache Commons Compress, from 1.21 to 1.26. Users are recommended to upgrade to MTR 1.2.5, which resolves this issue. For more details, see (CVE-2024-26308) . CVE-2024-1300: A vulnerability in the Eclipse Vert.x toolkit causes a memory leak in TCP servers configured with TLS and SNI support A vulnerability in the Eclipse Vert.x toolkit causes a memory leak in Transmission Control Protocol (TCP) servers configured with TLS and SNI support. When processing an unknown Server Name Indication (SNI) server name assigned the default certificate instead of a mapped certificate, the Secure Sockets Layer (SSL) context is erroneously cached in the server name map, leading to memory exhaustion. This affects only TLS servers with SNI enabled. Users are recommended to upgrade to MTR 1.2.5, which resolves this issue. For more details, see (CVE-2024-1300) . For a complete list of all issues resolved in this release, see the list of MTR 1.2.5 resolved issues in Jira.

Commands:
5.56. dvd+rw-tools 5.56.1. RHBA-2012:1320 - dvd+rw-tools bug fix update Updated dvd+rw-tools packages that fix one bug are now available for Red Hat Enterprise Linux 6. The dvd+rw-tools packages contain a collection of tools to master DVD+RW/+R media. Bug Fix BZ# 807474 Prior to this update, the growisofs utility wrote chunks of 32KB and reported an error during the last chunk when burning ISO image files that were not aligned to 32KB. This update allows the written chunk to be smaller than a multiple of 16 blocks. All users of dvd+rw-tools are advised to upgrade to these updated packages, which fix this bug.

Commands:
10.5.9.5. MinSpareThreads and MaxSpareThreads These values are only used with the worker MPM. They adjust how the Apache HTTP Server dynamically adapts to the perceived load by maintaining an appropriate number of spare server threads based on the number of incoming requests. The server checks the number of server threads waiting for a request and kills some if there are more than MaxSpareThreads or creates some if the number of servers is less than MinSpareThreads . The default MinSpareThreads value is 25 ; the default MaxSpareThreads value is 75 . These default settings should be appropriate for most situations. The value for MaxSpareThreads must be greater than or equal to the sum of MinSpareThreads and ThreadsPerChild , else the Apache HTTP Server automatically corrects it.

Commands:
5.9.2.2. EXT3 The ext3 file system builds upon ext2 by adding journaling capabilities to the already-proven ext2 codebase. As a journaling file system, ext3 always keeps the file system in a consistent state, eliminating the need for lengthy file system integrity checks. This is accomplished by writing all file system changes to an on-disk journal, which is then flushed on a regular basis. After an unexpected system event (such as a power outage or system crash), the only operation that needs to take place prior to making the file system available is to process the contents of the journal; in most cases this takes approximately one second. Because ext3's on-disk data format is based on ext2, it is possible to access an ext3 file system on any system capable of reading and writing an ext2 file system (without the benefit of journaling, however). This can be a sizable benefit in organizations where some systems are using ext3 and some are still using ext2.

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 You must complete the installation procedure for your environment. You must have an AMQP 1.0 message broker listening for connections on interface localhost and port 5672 . It must have anonymous access enabled. For more information, see Starting the broker . You must have a queue named examples . For more information, see Creating a queue . 3.2. Running Hello World on Red Hat Enterprise Linux The Hello World example creates a connection to the broker, sends a message containing a greeting to the examples queue, and receives it back. On success, it prints the received message to the console. Change to the examples directory and run the helloworld.py example. USD cd /usr/share/proton/examples/python/ USD python helloworld.py Hello World! 3.3. Running Hello World on Microsoft Windows The Hello World example creates a connection to the broker, sends a message containing a greeting to the examples queue, and receives it back. On success, it prints the received message to the console. Download and run the Hello World example. > curl -o helloworld.py https://raw.githubusercontent.com/apache/qpid-proton/master/python/examples/helloworld.py > python helloworld.py Hello World!

Commands:
cd /usr/share/proton/examples/python/ python helloworld.py Hello World!
> curl -o helloworld.py https://raw.githubusercontent.com/apache/qpid-proton/master/python/examples/helloworld.py > python helloworld.py Hello World!
Chapter 1. User Management 1.1. User Management As a cloud administrator, you can add, modify, and delete users in the dashboard. Users can be members of one or more projects. You can manage projects and users independently from each other. 1.1.1. Create a User Use this procedure to create users in the dashboard. You can assign a primary project and role to the user. Note that users created in the dashboard are Keystone users by default. To integrate Active Directory users, you can configure the LDAP provider included in the Red Hat OpenStack Platform Identity service. As an admin user in the dashboard, select Identity > Users . Click Create User . Enter a user name, email, and preliminary password for the user. Select a project from the Primary Project list. Select a role for the user from the Role list (the default role is _member_ ). Click Create User . 1.1.2. Edit a User Use this procedure to update the user's details, including the primary project. As an admin user in the dashboard, select Identity > Users . In the User's Actions column, click Edit . In the Update User window, you can update the User Name , Email , and Primary Project . Click Update User . 1.1.3. Enable or Disable a User Use this procedure to enable or disable a user. You can disable or enable only one user at a time. A disabled user cannot log in to the dashboard, and does not have access to any OpenStack services. Also, a disabled user's primary project cannot be set as active. A disabled user can be enabled again, unlike deleting a user where the action cannot be reversed. A disabled user must be re-enabled for any user-project action in the dashboard. As an admin user in the dashboard, select Identity > Users . In the Actions column, click the arrow, and select Enable User or Disable User . In the Enabled column, the value then updates to either True or False . 1.1.4. Delete a User As an admin user, use this procedure to delete a user using the dashboard. This action cannot be reversed, unlike disabling a user. Deleted users get delisted from a project's members' list for projects it belongs to. All roles associated with the user-project pair are also lost. As an admin user in the dashboard, select Identity > Users . Select the users you want to delete. Click Delete Users . The Confirm Delete Users window is displayed. Click Delete Users to confirm the action.

Commands:
B.71. poppler B.71.1. RHSA-2010:0859 - Important: poppler security update Updated poppler packages that fix three security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. 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. Poppler is a Portable Document Format (PDF) rendering library, used by applications such as Evince. CVE-2010-3702 , CVE-2010-3703 Two uninitialized pointer use flaws were discovered in poppler. An attacker could create a malicious PDF file that, when opened, would cause applications that use poppler (such as Evince) to crash or, potentially, execute arbitrary code. CVE-2010-3704 An array index error was found in the way poppler parsed PostScript Type 1 fonts embedded in PDF documents. An attacker could create a malicious PDF file that, when opened, would cause applications that use poppler (such as Evince) to crash or, potentially, execute arbitrary code. Users are advised to upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
8.3.3. Nikto Nikto is an excellent common gateway interface (CGI) script scanner. Nikto not only checks for CGI vulnerabilities but does so in an evasive manner, so as to elude intrusion detection systems. It comes with thorough documentation which should be carefully reviewed prior to running the program. If you have Web servers serving up CGI scripts, Nikto can be an excellent resource for checking the security of these servers. Note Nikto is not included with Red Hat Enterprise Linux and is not supported. It has been included in this document as a reference to users who may be interested in using this popular application. More information about Nikto can be found at the following URL: http://www.cirt.net/code/nikto.shtml

Commands:
Chapter 1. Installation Overview The self-hosted engine installation uses Ansible and the RHV-M Appliance (a pre-configured Manager virtual machine image) to automate the following tasks: Configuring the first self-hosted engine node Installing a Red Hat Enterprise Linux virtual machine on that node Installing and configuring the Red Hat Virtualization Manager on that virtual machine Configuring the self-hosted engine storage domain Note The RHV-M Appliance is only used during installation. It is not used to upgrade the Manager. Installing a self-hosted engine environment involves the following steps: Prepare storage to use for the self-hosted engine storage domain and for standard storage domains. You can use one of the following storage types: NFS iSCSI Fibre Channel (FCP) Red Hat Gluster Storage Install a deployment host to run the installation on. This host will become the first self-hosted engine node. You can use either host type: Red Hat Virtualization Host Red Hat Enterprise Linux Install and configure the Red Hat Virtualization Manager: Install the self-hosted engine using the hosted-engine --deploy command on the deployment host. Register the Manager with the Content Delivery Network and enable the Red Hat Virtualization Manager repositories. Connect to the Administration Portal to add hosts and storage domains. Add more self-hosted engine nodes and standard hosts to the Manager. Self-hosted engine nodes can run the Manager virtual machine and other virtual machines. Standard hosts can run all other virtual machines, but not the Manager virtual machine. Use either host type, or both: Red Hat Virtualization Host Red Hat Enterprise Linux Add hosts to the Manager as self-hosted engine nodes. Add hosts to the Manager as standard hosts. Add more storage domains to the Manager. The self-hosted engine storage domain is not recommended for use by anything other than the Manager virtual machine. If you want to host any databases or services on a server separate from the Manager, you can migrate them after the installation is complete. Important Keep the environment up to date. See https://access.redhat.com/articles/2974891 for more information. Since bug fixes for known issues are frequently released, Red Hat recommends using scheduled tasks to update the hosts and the Manager.

Commands:
Chapter 16. Applying security context to AMQ Streams pods and containers Security context defines constraints on pods and containers. By specifying a security context, pods and containers only have the permissions they need. For example, permissions can control runtime operations or access to resources. 16.1. Handling of security context by OpenShift platform Handling of security context depends on the tooling of the OpenShift platform you are using. For example, OpenShift uses built-in security context constraints (SCCs) to control permissions. SCCs are the settings and strategies that control the security features a pod has access to. By default, OpenShift injects security context configuration automatically. In most cases, this means you don't need to configure security context for the pods and containers created by the Cluster Operator. Although you can still create and manage your own SCCs. For more information, see the OpenShift documentation .

Commands:
4.8. Activating Logical Volumes on Individual Nodes in a Cluster If you have LVM installed in a cluster environment, you may at times need to activate logical volumes exclusively on one node. For example, the pvmove command is not cluster-aware and needs exclusive access to a volume. LVM snapshots require exclusive access to a volume as well. To activate logical volumes exclusively on one node, use the lvchange -aey command. Alternatively, you can use lvchange -aly command to activate logical volumes only on the local node but not exclusively. You can later activate them on additional nodes concurrently. You can also activate logical volumes on individual nodes by using LVM tags, which are described in Appendix C, LVM Object Tags . You can also specify activation of nodes in the configuration file, which is described in Appendix B, The LVM Configuration Files .

Commands:
Chapter 2. Installing standalone Hammer You can install Hammer on a host running RHEL that has no Satellite Server installed, and use it to connect from the host to a remote Satellite. Prerequisites Ensure that you register the host to Satellite Server or Capsule Server. If you are installing on Red Hat Enterprise Linux 9, ensure that the following repositories are enabled and synchronized on Satellite Server: rhel-9-for-x86_64-baseos-rpms rhel-9-for-x86_64-appstream-rpms satellite-utils-6.16-for-rhel-9-x86_64-rpms If you are installing on Red Hat Enterprise Linux 8, ensure that the following repositories are enabled and synchronized on Satellite Server: rhel-8-for-x86_64-baseos-rpms rhel-8-for-x86_64-appstream-rpms satellite-utils-6.16-for-rhel-8-x86_64-rpms Procedure Enable the required repositories on the host. If you are installing on Red Hat Enterprise Linux 8, enable the following module: Install Hammer CLI: Set the :host: entry in the /etc/hammer/cli.modules.d/foreman.yml file to the Satellite URL: Additional resources Enabling repositories on hosts in Managing hosts Registering Hosts in Managing hosts Synchronizing Repositories in Managing content

Commands:
dnf module enable satellite-utils:el8
dnf install satellite-cli
:host: 'https:// satellite.example.com '
15.6. Displaying Guest Details You can use the Virtual Machine Monitor to view activity information for any virtual machines on your system. To view a virtual system's details: In the Virtual Machine Manager main window, highlight the virtual machine that you want to view. Figure 15.10. Selecting a virtual machine to display From the Virtual Machine Manager Edit menu, select Virtual Machine Details . Figure 15.11. Displaying the virtual machine details When the Virtual Machine details window opens, there may be a console displayed. Should this happen, click View and then select Details . The Overview window opens first by default. To go back to this window, select Overview from the navigation pane on the left hand side. The Overview view shows a summary of configuration details for the guest. Figure 15.12. Displaying guest details overview Select Performance from the navigation pane on the left hand side. The Performance view shows a summary of guest performance, including CPU and Memory usage. Figure 15.13. Displaying guest performance details Select Processor from the navigation pane on the left hand side. The Processor view allows you to view the current processor allocation, as well as to change it. It is also possible to change the number of virtual CPUs (vCPUs) while the virtual machine is running, which is referred to as hot plugging and hot unplugging . Important The hot unplugging feature is only available as a Technology Preview. Therefore, it is not supported and not recommended for use in high-value deployments. Figure 15.14. Processor allocation panel Select Memory from the navigation pane on the left hand side. The Memory view allows you to view or change the current memory allocation. Figure 15.15. Displaying memory allocation Each virtual disk attached to the virtual machine is displayed in the navigation pane. Click on a virtual disk to modify or remove it. Figure 15.16. Displaying disk configuration Each virtual network interface attached to the virtual machine is displayed in the navigation pane. Click on a virtual network interface to modify or remove it. Figure 15.17. Displaying network configuration

Commands:
3.9. Other XFS File System Utilities Red Hat Enterprise Linux 7 also features other utilities for managing XFS file systems: xfs_fsr Used to defragment mounted XFS file systems. When invoked with no arguments, xfs_fsr defragments all regular files in all mounted XFS file systems. This utility also allows users to suspend a defragmentation at a specified time and resume from where it left off later. In addition, xfs_fsr also allows the defragmentation of only one file, as in xfs_fsr /path/to/file . Red Hat advises not to periodically defrag an entire file system because XFS avoids fragmentation by default. System wide defragmentation could cause the side effect of fragmentation in free space. xfs_bmap Prints the map of disk blocks used by files in an XFS filesystem. This map lists each extent used by a specified file, as well as regions in the file with no corresponding blocks (that is, holes). xfs_info Prints XFS file system information. xfs_admin Changes the parameters of an XFS file system. The xfs_admin utility can only modify parameters of unmounted devices or file systems. xfs_copy Copies the contents of an entire XFS file system to one or more targets in parallel. The following utilities are also useful in debugging and analyzing XFS file systems: xfs_metadump Copies XFS file system metadata to a file. Red Hat only supports using the xfs_metadump utility to copy unmounted file systems or read-only mounted file systems; otherwise, generated dumps could be corrupted or inconsistent. xfs_mdrestore Restores an XFS metadump image (generated using xfs_metadump ) to a file system image. xfs_db Debugs an XFS file system. For more information about these utilities, see their respective man pages.

Commands:
23.16. Write Changes to Disk The installer prompts you to confirm the partitioning options that you selected. Click Write changes to disk to allow the installer to partition your hard drive and install Red Hat Enterprise Linux. Figure 23.45. Writing storage configuration to disk If you are certain that you want to proceed, click Write changes to disk . Warning Up to this point in the installation process, the installer has made no lasting changes to your computer. When you click Write changes to disk , the installer will allocate space on your hard drive and start to transfer Red Hat Enterprise Linux into this space. Depending on the partitioning option that you chose, this process might include erasing data that already exists on your computer. To revise any of the choices that you made up to this point, click Go back . To cancel installation completely, switch off your computer. After you click Write changes to disk , allow the installation process to complete. If the process is interrupted (for example, by you switching off or resetting the computer, or by a power outage) you will probably not be able to use your computer until you restart and complete the Red Hat Enterprise Linux installation process, or install a different operating system.

Commands:
Chapter 16. Changing Variable Values Overview When the Camel debugger hits a breakpoint, the Variables view displays the values of all variables available at that point in the routing context. Some variables are editable, allowing you to change their value. This enables you to see how the application handles changes in program state. Note Not all variables are editable. The context menu of editable variables displays the Change Value... option. Procedure To change the value of a variable: If necessary, start the debugger. See Chapter 14, Running the Camel Debugger . In the Variables view, select a variable whose value you want to change, and then click its Value field. The variable's value field turns a lighter shade of blue, indicating that it is in edit mode. Note Alternatively, you can right-click the variable to open its context menu, and select Change Value... to edit its value. Enter the new value and then click Enter . The Console view displays an INFO level log entry noting the change in the variable's value (for example, Breakpoint at node to1 is updating message header on exchangeId: ID-dhcp-97-16-bos-redhat-com-52574-1417298894070-0-2 with header: Destination and value: UNITED KINGDOM ). Continue stepping through the breakpoints and check whether the message is processed as expected. At each step, check the Debug view, the Variables view, and the Console output. Related topics Chapter 18, Disabling Breakpoints in a Running Context Chapter 17, Adding Variables to the Watch List

Commands: