mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Connecting cloud integrations to the subscriptions service Data collection for certain pay-as-you-go On-Demand subscriptions requires a connection known as a cloud integration, configured with the integrations service of the Hybrid Cloud Console. A cloud integration on the Red Hat Hybrid Cloud Console is a connection to a service, application, or provider that supplies data to another Hybrid Cloud Console service. Through a cloud integration, the connected service can connect with and use data from public cloud providers and other services or tools to collect data for that service. Note When a cloud integration is required to track the usage of a subscription, the post-purchase enablement steps generally include information about this requirement. These post-purchase enablement instructions might contain more current information about setting up the cloud integration. The following products require the configuration of a cloud integration to enable data collection for the subscriptions service: Red Hat Enterprise Linux for Third Party Linux Migration with Extended Life Cycle Support Add-on, metered with the the cost management service method If you want to use the cost management service to meter the usage of RHEL for Third Party Linux Migration with ELS in the subscriptions service, you must create a cloud integration. The configuration of a cloud integration for includes a creating a connection between a cloud provider and the cost management service in the Hybrid Cloud Console. This cloud integration ensures that usage data from the cloud provider and from the cost management service is used to calculate metered usage in the subscriptions service and that usage data is returned to the cloud provider for billing purposes. Procedure For Red Hat Enterprise Linux for Third Party Linux Migration with Extended Life Cycle Support Add-on The post-purchase enablement steps for RHEL for Third Party Linux Migration with ELS include information about setting up the required cloud integration, in addition to other setup information required for the subscription. To ensure that your cloud integration is configured correctly for use by the subscriptions service, review the following information and confirm that the cloud integration configuration steps were completed: For more information about the RHEL for Third Party Linux Migration with ELS post-purchase enablement steps, including the step to set up a cloud integration, see the Getting Started with Red Hat Enterprise Linux for Third Party Linux Migration Customer Portal support article. For more information about cloud integrations, see Configuring cloud integrations for Red Hat services For more information about setting up a cloud integration for the cost management service and a specific cloud platform, see Adding integrations to cost management in the cost management documentation.

Commands:
probe::ioscheduler.elv_next_request.return Name probe::ioscheduler.elv_next_request.return - Fires when a request retrieval issues a return signal Synopsis ioscheduler.elv_next_request.return Values disk_major Disk major number of the request disk_minor Disk minor number of the request rq_flags Request flags rq Address of the request name Name of the probe point

Commands:
E.2.5. /proc/devices This file displays the various character and block devices currently configured (not including devices whose modules are not loaded). Below is a sample output from this file: The output from /proc/devices includes the major number and name of the device, and is broken into two major sections: Character devices and Block devices . Character devices are similar to block devices , except for two basic differences: Character devices do not require buffering. Block devices have a buffer available, allowing them to order requests before addressing them. This is important for devices designed to store information - such as hard drives - because the ability to order the information before writing it to the device allows it to be placed in a more efficient order. Character devices send data with no preconfigured size. Block devices can send and receive information in blocks of a size configured per device. For more information about devices, see the devices.txt file in the kernel-doc package (see Section E.5, "Additional Resources" ).

Commands:
Character devices: 1 mem 4 /dev/vc/0 4 tty 4 ttyS 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 10 misc 13 input 29 fb 36 netlink 128 ptm 136 pts 180 usb Block devices: 1 ramdisk 3 ide0 9 md 22 ide1 253 device-mapper 254 mdp
Chapter 1. Introduction to Directory Server Performance Tuning This article provides some procedures and options that administrators can use to optimize the performance of their Red Hat Directory Server deployments. Performance tuning a Directory Server instance is unique to each server because of differences for every server in its machine environment, directory size and data type, load and network use, even the types of operations that users and clients perform. The purpose of this guide is to highlight the features that Red Hat Directory Server provides for tracking and assessing server and database performance. There are also some procedures given to help tune server performance. For more in-depth planning information, however, check out the Red Hat Directory Server Deployment Guide , and for for command-line and UI-based administrative instructions, see the Red Hat Directory Server Administration Guide . 1.1. Setting Goals for Directory Server Performance Performance tuning is simply a way to identify potential (or real) bottlenecks in the normal operating environment of the server and then taking steps to mitigate those bottlenecks. The general plan for performance tuning is: Assess the environment. Look at everything around the Directory Server: its usage, the load, the network connection and reliability, most common operations, the physical machine its on, along with any services competing for its resources. Measure the current Directory Server performance and establish baselines. Identify the server areas which can be improved. Make any changes to the Directory Server settings and, potentially, to the host machine. Measure the Directory Server performance again to see how the changes affected the performance. Directory Server provides some sort of monitoring in three areas: The server process (counters and logs) The databases (counters) Any database links (counters) In the Directory Server, most performance measurements are going to be how well the Directory Server retrieves and delivers information to clients. With that in mind, these are the server areas that can be tuned for the best Directory Server performance (and these are the areas covered in this article): Search operations Indexing performance (which affects both search and write operations) Database transactions Database and entry cache settings Database links Other changes can be made to the host machine's settings or hardware which can also affect Directory Server performance: Available memory (based on directory size) Other servers running on the same machine (which could compete for resources) Distributing user databases across other Directory Server instances on other machines Balancing server loads due to network performance These changes relate much more to planning an effective Directory Server deployment than changes that can be made to an instance. Reviewing the Deployment Guide can provide more detail about how to plan an optimal enterprise deployment.

Commands:
A.11. VDSM Hook Examples The example hook scripts provided in this section are strictly not supported by Red Hat. You must ensure that any and all hook scripts that you install to your system, regardless of source, are thoroughly tested for your environment. Example A.5. NUMA Node Tuning Purpose: This hook script allows for tuning the allocation of memory on a NUMA host based on the numaset custom property. Where the custom property is not set no action is taken. Configuration String: The regular expression used allows the numaset custom property for a given virtual machine to specify both the allocation mode ( interleave , strict , preferred ) and the node to use. The two values are separated by a colon ( : ). The regular expression allows specification of the nodeset as: that a specific node ( numaset=strict:1 , specifies that only node 1 be used), or that a range of nodes be used ( numaset=strict:1-4 , specifies that nodes 1 through 4 be used), or that a specific node not be used ( numaset=strict:^3 , specifies that node 3 not be used), or any comma-separated combination of the above ( numaset=strict:1-4,6 , specifies that nodes 1 to 4, and 6 be used). Script: /usr/libexec/vdsm/hooks/before_vm_start/50_numa

Commands:
numaset=^(interleave|strict|preferred):[\^]?\d+(-\d+)?(,[\^]?\d+(-\d+)?)*USD
#!/usr/bin/python import os import sys import hooking import traceback ''' numa hook ========= add numa support for domain xml: <numatune> <memory mode="strict" nodeset="1-4,^3" /> </numatune> memory=interleave|strict|preferred numaset="1" (use one NUMA node) numaset="1-4" (use 1-4 NUMA nodes) numaset="^3" (don't use NUMA node 3) numaset="1-4,^3,6" (or combinations) syntax: numa=strict:1-4 ''' if os.environ.has_key('numa'): try: mode, nodeset = os.environ['numa'].split(':') domxml = hooking.read_domxml() domain = domxml.getElementsByTagName('domain')[0] numas = domxml.getElementsByTagName('numatune') if not len(numas) > 0: numatune = domxml.createElement('numatune') domain.appendChild(numatune) memory = domxml.createElement('memory') memory.setAttribute('mode', mode) memory.setAttribute('nodeset', nodeset) numatune.appendChild(memory) hooking.write_domxml(domxml) else: sys.stderr.write('numa: numa already exists in domain xml') sys.exit(2) except: sys.stderr.write('numa: [unexpected error]: %s\n' % traceback.format_exc()) sys.exit(2)
19.7. Directory Operations In order to improve the performance of directory operations of Red Hat Gluster Storage volumes, the maximum metadata (stat, xattr) caching time on the client side is increased to 10 minutes, without compromising on the consistency of the cache. Significant performance improvements can be achieved in the following workloads by enabling metadata caching: Listing of directories (recursive) Creating files Deleting files Renaming files 19.7.1. Enabling Metadata Caching Enable metadata caching to improve the performance of directory operations. Execute the following commands from any one of the nodes on the trusted storage pool in the order mentioned below. Note If majority of the workload is modifying the same set of files and directories simultaneously from multiple clients, then enabling metadata caching might not provide the desired performance improvement. Execute the following command to enable metadata caching and cache invalidation: This is group set option which sets multiple volume options in a single command. To increase the number of files that can be cached, execute the following command: n , is set to 50000. It can be increased if the number of active files in the volume is very high. Increasing this number increases the memory footprint of the brick processes.

Commands:
gluster volume set < volname > group metadata-cache
gluster volume set < VOLNAME > network.inode-lru-limit < n >
5.119. jakarta-commons-httpclient 5.119.1. RHSA-2013:0270 - Moderate: jakarta-commons-httpclient security update Updated jakarta-commons-httpclient packages that fix one security issue are now available for Red Hat Enterprise Linux 5 and 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. The Jakarta Commons HttpClient component can be used to build HTTP-aware client applications (such as web browsers and web service clients). Security Fix CVE-2012-5783 The Jakarta Commons HttpClient component did not verify that the server hostname matched the domain name in the subject's Common Name (CN) or subjectAltName field in X.509 certificates. This could allow a man-in-the-middle attacker to spoof an SSL server if they had a certificate that was valid for any domain name. All users of jakarta-commons-httpclient are advised to upgrade to these updated packages, which correct this issue. Applications using the Jakarta Commons HttpClient component must be restarted for this update to take effect.

Commands:
Chapter 12. Configuring CUPS to store logs in files instead of the systemd journal By default, CUPS stores log messages in the systemd journal. Alternatively, you can configure CUPS to store log messages in files. Prerequisites CUPS is installed . Procedure Edit the /etc/cups/cups-files.conf file, and set the AccessLog , ErrorLog , and PageLog parameters to the paths where you want to store these log files: If you configure CUPS to store the logs in a directory other than /var/log/cups/ , set the cupsd_log_t SELinux context on this directory, for example: Restart the cups service: Verification Display the log files: If you configured CUPS to store the logs in a directory other than /var/log/cups/ , verify that the SELinux context on the log directory is cupsd_log_t :

Commands:
AccessLog /var/log/cups/access_log ErrorLog /var/log/cups/error_log PageLog /var/log/cups/page_log
semanage fcontext -a -t cupsd_log_t " /var/log/printing (/.*)?" restorecon -Rv /var/log/printing/
systemctl restart cups
cat /var/log/cups/access_log cat /var/log/cups/error_log cat /var/log/cups/page_log
ls -ldZ /var/log/printing/ drwxr-xr-x. 2 lp sys unconfined_u:object_r: cupsd_log_t :s0 6 Jun 20 15:55 /var/log/printing/
25.7. Changing the Password or Public Key of a Vault The owner of a vault can change the vault's password. Depending on whether the vault is symmetric or asymmetric, the command differs: To change the password of a symmetric vault: To change the public key of an asymmetric vault:

Commands:
ipa vault-mod --change-password Vault name: example_symmetric_vault Password: old_password New password: new_password Enter New password again to verify: new_password ----------------------- Modified vault " example_symmetric_vault " ----------------------- Vault name: example_symmetric_vault Type: symmetric Salt: dT+M+4ik/ltgnpstmCG1sw== Owner users: admin Vault user: admin
ipa vault-mod example_asymmetric_vault --private-key-file= old_private_key.pem --public-key-file= new_public_key.pem ------------------------------- Modified vault " example_assymmetric_vault " ------------------------------- Vault name: example_assymmetric_vault Typ: asymmetric Public key: Owner users: admin Vault user: admin
Chapter 52. Compiler and Tools GCC thread sanitizer included in RHEL no longer works Due to incompatible changes in kernel memory mapping, the thread sanitizer included with the GNU C Compiler (GCC) compiler version in RHEL no longer works. Additionally, the thread sanitizer cannot be adapted to the incompatible memory layout. As a result, it is no longer possible to use the GCC thread sanitizer included with RHEL. As a workaround, use the version of GCC included in Red Hat Developer Toolset to build code which uses the thread sanitizer. (BZ#1569484) ksh with the KEYBD trap mishandles multibyte characters The Korn Shell (KSH) is unable to correctly handle multibyte characters when the KEYBD trap is enabled. Consequently, when the user enters, for example, Japanese characters, ksh displays an incorrect string. To work around this problem, disable the KEYBD trap in the /etc/kshrc file by commenting out the following line: For more details, see a related Knowledgebase solution . (BZ# 1503922 )

Commands:
trap keybd_trap KEYBD
Chapter 1. Red Hat build of OpenJDK 11 - End of full support Important The 11.0.25 release is the last release of Red Hat build of OpenJDK 11 that Red Hat plans to fully support. The full support for Red Hat build of OpenJDK 11 ends on 31 October 2024. See the Product Life Cycles page for details. Red Hat will provide extended life cycle support (ELS) phase 1 support for Red Hat build of OpenJDK 11 until 31 October 2027. For more information about product life cycle phases and available support levels, see Life Cycle Phases . For information about migrating to Red Hat build of OpenJDK version 17 or 21, see Migrating to Red Hat build of OpenJDK 17 from earlier versions or Migrating to Red Hat build of OpenJDK 21 from earlier versions .

Commands:
7.216. tomcatjss 7.216.1. RHBA-2015:1316 - tomcatjss bug fix and enhancement update An updated tomcatjss package that fixes one bug and adds one enhancement is now available for Red Hat Enterprise Linux 6. The tomcatjss package provides a Java Secure Socket Extension (JSSE) implementation using Java Security Services (JSS) for Tomcat, an open source web server and Java servlet container. Bug Fix BZ# 1190911 Previously, the init() function in tomcatjss looked for the clientauth attribute which was not present. As a consequence, Tomcat returned NullPointerException in init() on startup, and in addition, some properties, such as enableOSCP and properties for enabling certain SSL ciphers, were not called. A patch has been applied to fix this problem. As a result, NullPointerException no longer occurs in the described situation, and the mentioned properties are called as expected. Enhancement BZ# 1167471 The Tomcat service has been updated to support the Transport Layer Security cryptographic protocol version 1.1 (TLSv1.1) and the Transport Layer Security cryptographic protocol version 1.2 (TLSv1.2) using JSS. Users of tomcatjss are advised to upgrade to this updated package, which fixes this bug and adds this enhancement.

Commands:
Chapter 14. Constant Overview The constant language is a trivial built-in language that is used to specify a plain text string. This makes it possible to provide a plain text string in any context where an expression type is expected. XML example In XML, you can set the username header to the value, Jane Doe as follows: Java example In Java, you can set the username header to the value, Jane Doe as follows:

Commands:
<camelContext> <route> <from uri=" SourceURL "/> <setHeader headerName="username"> <constant>Jane Doe</constant> </setHeader> <to uri=" TargetURL "/> </route> </camelContext>
from(" SourceURL ") .setHeader("username", constant("Jane Doe")) .to(" TargetURL ");
4.229. pinentry 4.229.1. RHBA-2011:1096 - pinentry bug fix update Updated pinentry packages that fix one bug are now available for Red Hat Enterprise Linux 6. The pinentry package contains a collection of simple PIN or password entry dialogs, which utilize the Assuan protocol as described by the Project Aegypten. The pinentry package also contains the command line version of the PIN entry dialog. Bug Fix BZ# 677665 Prior to this update, there was a problem when entering a password using the pinentry-curses utility; an error message was displayed instead of the password entry dialog if pinentry-curses was run under a user different from the user who owned the current tty. This bug has been fixed in this update so that no error message is now displayed and pinentry-curses asks for a password as expected. All users of pinentry are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 19. Remove Red Hat JBoss Data Grid 19.1. Remove Red Hat JBoss Data Grid from Your Linux System The following procedures contain instructions to remove Red Hat JBoss Data Grid from your Linux system. Warning Once deleted, all JBoss Data Grid configuration and settings are permanently lost. Procedure 19.1. Remove JBoss Data Grid from Your Linux System Shut Down Server Ensure that the JBoss Data Grid server is shut down. Navigate to the JBoss Data Grid Home Directory Use the command line to change into the level above the USDJDG_HOME folder. Delete the JBoss Data Grid Home Directory Enter the following command in the terminal to remove JBoss Data Grid, replacing USDJDG_HOME with the name of your JBoss Data Grid home directory: Report a bug

Commands:
rm -Rf USDJDG_HOME
probe::irq_handler.entry Name probe::irq_handler.entry - Execution of interrupt handler starting Synopsis irq_handler.entry Values next_irqaction pointer to irqaction for shared interrupts thread_fn interrupt handler function for threaded interrupts thread thread pointer for threaded interrupts thread_flags Flags related to thread irq irq number flags_str symbolic string representation of IRQ flags dev_name name of device action struct irqaction* for this interrupt num dir pointer to the proc/irq/NN/name entry flags Flags for IRQ handler dev_id Cookie to identify device handler interrupt handler function

Commands:
2.8.3.3. Saving and Restoring IPTables Rules Changes to iptables are transitory; if the system is rebooted or if the iptables service is restarted, the rules are automatically flushed and reset. To save the rules so that they are loaded when the iptables service is started, use the following command as the root user: The rules are stored in the file /etc/sysconfig/iptables and are applied whenever the service is started or the machine is rebooted.

Commands:
~]# service iptables save iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
Chapter 36. Disabling Anonymous Binds Accessing domain resources and running client tools always require Kerberos authentication. However, the back end LDAP directory used by the IdM server allows anonymous binds by default. This potentially opens up all of the domain configuration to unauthorized users, including information about users, machines, groups, services, netgroups, and DNS configuration. It is possible to disable anonymous binds on the 389 Directory Server instance by using LDAP tools to reset the nsslapd-allow-anonymous-access attribute. Warning Certain clients rely on anonymous binds to discover IdM settings. Additionally, the compat tree can break for legacy clients that are not using authentication. Change the nsslapd-allow-anonymous-access attribute to rootdse . Important Anonymous access can be completely allowed (on) or completely blocked (off). However, completely blocking anonymous access also blocks external clients from checking the server configuration. LDAP and web clients are not necessarily domain clients, so they connect anonymously to read the root DSE file to get connection information. The rootdse allows access to the root DSE and server configuration without any access to the directory data. Restart the 389 Directory Server instance to load the new setting. Additional Resources: The Managing Entries Using the Command Line section in the Red Hat Directory Server Administration Guide .

Commands:
ldapmodify -x -D "cn=Directory Manager" -W -h server.example.com -p 389 -ZZ Enter LDAP Password: dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: rootdse modifying entry "cn=config"
systemctl restart dirsrv.target