mtpti5iD/redhat-docs_dataset huggingface dataset:
13.13. Compatibility Between Server and Hot Rod Client Versions Hot Rod clients, such as the Hot Rod Java, Hot Rod C++, and Hot Rod C#, are compatible with different versions of Red Hat JBoss Data Grid server. The server should be of the latest version in order to run with different Hot Rod clients. Note It is recommended to use the same version of the Hot Rod client and the JBoss Data Grid server, except in a case of migration or upgrade, to prevent any known problems. Consider the following scenarios. Scenario 1: Server running on a newer version than the Hot Rod client. The following will be the impact on the client side: client will not have advantage of the latest protocol improvements. client might run into known issues which are fixed for the server-side version. client can only use the functionalities available in its current version and the versions. Scenario 2: Hot Rod client running on a newer version than the server. In this case, when a Hot Rod client connects to a JBoss Data Grid server, the connection will be rejected with an exception error. The client can be downgraded to a known protocol version by setting the client side property - org.infinispan.client.hotrod.configuration.ConfigurationBuilder.protocolVersion to a specific version, such as Hot Rod 1.3, as a String. In this case the client is able to connect to the server, but will be restricted to the functionality of that version. Any command which is not supported by this protocol version will not work and throw an exception. Also, the topology information might be inefficient in this case. Note It is not recommended to use this approach without guidance from Red Hat support. The following table details the compatibility between different Hor Rod client and server versions. Table 13.47. Hot Rod client and server compatibility JBoss Data Grid Server Version Hot Rod Protocol Version JBoss Data Grid 6.6.1 Hot Rod 2.3 JBoss Data Grid 6.6.0 Hot Rod 2.3 JBoss Data Grid 6.5.1 Hot Rod 2.2 JBoss Data Grid 6.5.0 Hot Rod 2.2 JBoss Data Grid 6.4.1 Hot Rod 2.0 JBoss Data Grid 6.4.0 Hot Rod 2.0 JBoss Data Grid 6.3.2 Hot Rod 2.0 JBoss Data Grid 6.3.1 Hot Rod 2.0 JBoss Data Grid 6.3.0 Hot Rod 2.0 JBoss Data Grid 6.2.1 Hot Rod 1.3 JBoss Data Grid 6.2.0 Hot Rod 1.3 JBoss Data Grid 6.1.0 Hot Rod 1.2 JBoss Data Grid 6.0.1 Hot Rod 1.1 JBoss Data Grid 6.0.0 Hot Rod 1.1 Report a bug

Commands:
4. Feature Updates 4.1. All Architectures Bugzilla #469924 Systemtap is now a fully supported feature in Red Hat Enterprise Linux 4. systemtap provides a free software (GPL) infrastructure to simplify the gathering of information about the running Linux system. This assists diagnosis of a performance or functional problem. With the help of systemtap , developers no longer need to go through the tedious and disruptive sequence of instrument, recompile, install, and reboot that may be otherwise required to collect data. Note that some features of systemtap for newer Red Hat Enterprise Linux or Linux systems will not work on Red Hat Enterprise Linux 4 due to missing kernel features. The absence of the kernel utrace precludes support for any user-space probing. Bugzilla #459041 dmidecode gives information about BIOSes and motherboard revisions. The version of kernel-utils supplied with this advisory updates dmidecode from version 2.2 to version 2.9. This version identifies newer processors, PCI-express slots and devices, and blade chassis. It also offers enhanced support for the SMBIOS v2.6 specification. Bugzilla #453642 a new version of kernel-utils is included in this release, updating the Intel microcode file to version 20080910, to support newer Intel processors. Bugzilla #447979 smartmontools has been extended to support newer CCISS controllers found in newer HP ProLiant hardware. Bugzilla #460904 The Samba package has been rebased to the upstream version 3.0.33. The 3.0.x version series is a bugfix only branch of the Samba code base. By rebasing to 3.0.33 we will include a number of important bug fixes and security fixes. No new features will be added by this rebase. For more information on the upstream fixes provided by this rebase, refer to the Samba Release Notes: http://samba.org/samba/history/samba-3.0.33.html Bugzilla #454833 ipmitool has been updated to the upstream version 1.8.11, which provides several bug fixes and enhancements over the release, including the following: Documentation update Bugfixes for SDR/FRU, SOL and many others New commands and options Please note that behaviour of the -K command line switch has changed from prompt for Kg key to read Kg key from environment variable . The -Y flag now behaves as the -K did prior to this update.

Commands:
8.21. binutils 8.21.1. RHBA-2014:1414 - binutils bug fix update Updated binutils packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The binutils packages provide a collection of binary utilities for the manipulation of object code in various object file formats. It includes the "ar", "as", "gprof", "ld", "nm", "objcopy", "objdump", "ranlib", "readelf", "size", "strings", "strip", and "addr2line" utilities. Bug Fixes BZ# 1128279 Previously, the ld linker could overwrite a valid SONAME with an empty string in a DT_NEEDED record. Consequently, certain programs were linked but could not be executed because symbols from some libraries were not loaded. With this update, the ld linker correctly handles empty strings in SONAMEs, and programs linked by ld now can be executed as expected. BZ# 906079 When creating a shared library for a "ppc64" target, the ld linker selected linker stubs that were not thread-safe by default. Consequently, if such a shared library was used by a multi-threaded application, calls into the library could fail in unpredictable ways. To fix this problem, the ld linker now build shared libraries for "ppc64" targets with thread-safe linker stubs. BZ# 909056 The readelf utility incorrectly assumed that a long name table would always be available if an archive used long names. Consequently, readelf could terminate unexpectedly with a segmentation fault on archive libraries that used long names but did not have a long name table. To fix this problem, readelf now verifies the existence of a long name table on archive libraries. BZ# 959422 The ld linker incorrectly handled certain TLS relocations that appears in debugging (DWARF) sections. Consequently, debugging information for some variables in TLS sections could be incorrect. With this update, the ld linker now correctly handles TLS relocations in DWARF sections, and the related TLS variables now can be properly examined. Users of binutils are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 31. Publishing the certified Helm chart When you submit your Helm chart for validation, the Red Hat certification team will review and verify the entered details of the questionnaire. If you want to certify your Partner Validated chart, complete the Certification details. The Red Hat certification team will review the submitted test results. After successful verification, to publish your product on the Red Hat Ecosystem Catalog , go to the Product Listings page to attach the Partner Validated or Certified chart. When you submit the Helm chart for verification through a pull request, the Red Hat certification team reviews and verifies your component for certification. After successful verification, your Helm chart is certified through GitHub. Follow the steps to publish your certified Helm chart: Access the Partner connect web page. My Products web page displays the Product Listings . Navigate to the Product Listings tab and search for the required product listing. Click the newly created product listing that you wish to publish. Review all the details of your product listing. Go to the Components tab. Click Add component and go to Existing component tab to attach your certified Helm chart to this listing. Also add the certified containers used by your Helm chart. Both the components must be in Published status. The Publish button is enabled when you specify all the required information for the product listing along with the attached components. Note For Partner Validated components, this step is not required. The Publish button is enabled when you specify all the required information for the product listing, including the attached components. Click Publish . Your certified Helm chart is now available for public access on the Red Hat Ecosystem Catalog .

Commands:
8.7.2. Auditing System Settings with SCAP Security Guide The SCAP Security Guide (SSG) project's package, scap-security-guide , contains the latest set of security polices for Linux systems. Part of scap-security-guide is also a guidance for Red Hat Enterprise Linux 6 settings. To inspect the security content available with scap-security-guide , use the oscap info module: The output of this command is an outline of the SSG document and it contains available configuration profiles. To audit your system settings, choose a suitable profile and run the appropriate evaluation command. For example, the following command is used to assess the given system against a draft SCAP profile for Red Hat Certified Cloud Providers:

Commands:
~]USD oscap info /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
~]USD oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results ssg-rhel6-xccdf-result.xml --report ssg-rhel6-report.html /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
Appendix C. Creating an encrypted credentials.yml file This section describes how to create an encrypted credentials.yml file that is passed to the Ansible Automation Platform installer. Warning The passwords used must match between Environment A and Environment B . Within your initial Environment B Ansible Automation Platform environment, Create a credentials.yml file to store the encrypted credentials Encrypt the credentials.yml file using ansible-vault Warning The admin_password and pg_password credentials need to match the value used in your Ansible Automation Platform 1.2 Environment A . Warning Ensure to store your encrypted vault password in a safe location. Verify the credentials.yml file is encrypted Note The creation of encrypted credentials is optional but recommended as storing passwords within your inventory file should not be in plain text. If you are already using encrypted credentails, use your credentials.yml file instead of creating a new one.

Commands:
cat credentials.yml
admin_password: my_long_admin_password pg_password: my_long_pg_password registry_password: my_long_registry_password
ansible-vault encrypt credentials.yml
New Vault password: Confirm New Vault password: Encryption successful
cat credentials.yml
USDANSIBLE_VAULT;1.1;AES256 36383639653562386534316333333961383336306465336465613831353435313530376464616539 3765393063303065323466663330646232363065316666310a373062303133376339633831303033 34313534383962613632303761636632623932653062343839613639653635643365616233313365 3636616639313864300a353239373433313339613465326339313035633565353464356538653631 63346434383534643237663862353361366632613634333231316334363939396461326561643336 3430633534303935646264633034383966336232303365383763
5.9. Scheduling In Red Hat Virtualization, scheduling refers to the way the Red Hat Virtualization Manager selects a host in a cluster as the target for a new or migrated virtual machine. For a host to be eligible to start a virtual machine or accept a migrated virtual machine from another host, it must have enough free memory and CPUs to support the requirements of the virtual machine being started on or migrated to it. A virtual machine will not start on a host with an overloaded CPU. By default, a host's CPU is considered overloaded if it has a load of more than 80% for 5 minutes, but these values can be changed using scheduling policies. If multiple hosts are eligible targets, one will be selected based on the load balancing policy for the cluster. For example, if the Evenly_Distributed policy is in effect, the Manager chooses the host with the lowest CPU utilization. If the Power_Saving policy is in effect, the host with the lowest CPU utilization between the maximum and minimum service levels will be selected. The Storage Pool Manager (SPM) status of a given host also affects eligibility as a target for starting virtual machines or virtual machine migration. A non-SPM host is a preferred target host, for instance, the first virtual machine started in a cluster will not run on the SPM host if the SPM role is held by a host in that cluster. See Scheduling Policies in the Administration Guide for more information.

Commands:
Chapter 1. Nagios and Ceph Nagios Core is an open source solution for monitoring nodes. Large Red Hat Ceph Storage clusters benefit from distributed monitoring systems such as Nagios Core. The Nagios Core checks each node in a cluster, including the health of the underlying operating system, as well as the health of the Red Hat Ceph Storage cluster daemons. To deploy Nagios Core with Ceph requires: A running Red Hat Ceph Storage cluster. Instead of Nagios Core, you can also substitute the more feature rich commercial version, Nagios XI. Important Red Hat does not provide the Nagios packages. Important Red Hat works with our technology partners to provide this documentation as a service to our customers. However, Red Hat does not provide support for this product. If you need technical assistance for this product, then contact Nagios for support.

Commands:
Chapter 2. Why Ansible Automation Platform on Red Hat OpenShift? Running Ansible Automation Platform 2.3 on Red Hat OpenShift 4.x can provide a more efficient and automated way to deploy and manage the platform, as well as better integration with Red Hat OpenShift's built-in monitoring, logging, security, and scalability features. Additionally, using Red Hat OpenShift's Operator Lifecycle Manager (OLM) to deploy and manage the Ansible Automation Platform operator can simplify the update and upgrade process, allowing for more control and flexibility. A further breakdown of those benefits can be seen below: Automation: The Ansible Automation Platform operator provides a way to automate the deployment and management of the Ansible Automation Platform on Red Hat OpenShift. This can help you to reduce the time and effort required to deploy and manage the platform, and ensure that it is running in a consistent and predictable way. Scalability: The operator can help you to scale the Ansible Automation Platform to meet the needs of your organization. You can easily deploy multiple instances of the platform and manage them from a single location. Flexibility: The operator provides a flexible way to deploy and manage the Ansible Automation Platform. You can customize the configuration of the platform to suit your specific needs, and deploy it in different environments, such as development, staging, and production. Monitoring and troubleshooting: The operator integrates with Red Hat OpenShift's built-in monitoring and logging tools, like Prometheus and Grafana, which can be used to monitor the resource usage of the platform and identify any bottlenecks. Management and upgrade: Using the Operator Lifecycle Manager (OLM) that comes with Red Hat OpenShift 4.x, you can easily deploy, manage, and upgrade [1] the Ansible Automation Platform operator across your cluster. [1] Ansible Automation Platform supported lifecycle versions - https://access.redhat.com/support/policy/updates/ansible-automation-platform

Commands:
5.246. pm-utils 5.246.1. RHBA-2012:1094 - pm-utils bug fix update Updated pm-utils packages that fix one bug are now available for Red Hat Enterprise Linux 6. The pm-utils packages contain a set of utilities and scripts for tasks related to power management. Bug Fix BZ# 800630 Prior to this update, the RPM description contained wrong product names. This update removes all wrong information. All users of pm-utils are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 6. Pass-Through certification A Pass-Through Certification refers to the ability of a third-party system or component to be granted certification for hardware previously certified by the original hardware manufacturer. Pass-Through can reduce the overall amount of testing that is required to be performed and submitted to Red Hat to achieve certification for the third-party hardware. System manufacturers can extend a certification granted to their own systems to another vendor's system where the original vendor: Has permission from the third-party, Has the mechanics to ensure the third party does not alter the hardware in such a way that it would no longer be considered a subset of the original model certified by Red Hat, and Extends their responsibilities of support and representative hardware to include situations involving third-party hardware. The third-party cannot then extend their Pass-Through Certification to another vendor. While both vendors are required to be members of the Red Hat Hardware Certification Program, only the original vendor may request Pass-Through Certifications. Vendors may also utilize the Pass-Through process, where the same vendor has multiple names for the same hardware.

Commands:
A.12. numactl Numactl lets administrators run a process with a specified scheduling or memory placement policy. Numactl can also set a persistent policy for shared memory segments or files, and set the processor affinity and memory affinity of a process. Numactl provides a number of useful options. This appendix outlines some of these options and gives suggestions for their use, but is not exhaustive. --hardware Displays an inventory of available nodes on the system, including relative distances between nodes. --membind Ensures that memory is allocated only from specific nodes. If there is insufficient memory available in the specified location, allocation fails. --cpunodebind Ensures that a specified command and its child processes execute only on the specified node. --phycpubind Ensures that a specified command and its child processes execute only on the specified processor. --localalloc Specifies that memory should always be allocated from the local node. --preferred Specifies a preferred node from which to allocate memory. If memory cannot be allocated from this specified node, another node will be used as a fallback. For further details about these and other parameters, see the man page:

Commands:
man numactl
20.20. Creating a Virtual Machine XML Dump (Configuration File) The virsh dumpxml command will return the guest virtual machine's XML configuration file which you can then use, save, or change as needed. The XML file ( guest.xml ) can then be used to recreate the guest virtual machine (refer to Section 20.22, "Editing a Guest Virtual Machine's XML Configuration Settings" . You can edit this XML configuration file to configure additional devices or to deploy additional guest virtual machines. Example 20.48. How to retrieve the XML file for a guest virtual machine The following example retrieves the XML configuration of the guest1 virtual machine, writes it into the guest1.xml file, and then verifies that the process has been completed successfully.

Commands:
virsh dumpxml guest1 > guest1.xml cat guest1.xml <domain type='kvm'> <name>guest1-rhel6-64</name> <uuid>b8d7388a-bbf2-db3a-e962-b97ca6e514bd</uuid> <memory>2097152</memory> <currentMemory>2097152</currentMemory> <vcpu>2</vcpu> <os> <type arch='x86_64' machine='rhel6.2.0'>hvm</type> <boot dev='hd'/> </os> [...]
6.3.4. Select a PXE Target that Includes a Driver Update Select network boot in your computer's BIOS or boot menu. The procedure to specify this option varies widely among different computers. Consult your hardware documentation or the hardware vendor for specifics relevant to your computer. In the preboot execution environment (PXE), choose the boot target that you prepared on your PXE server. For example, if you labeled this environment rhel6-dd in the /var/lib/tftpboot/pxelinux/pxelinux.cfg/default file on your PXE server, type rhel6-dd at the prompt and press Enter . Refer to Section 6.2.3, "Preparing an Initial RAM Disk Update" and Chapter 30, Setting Up an Installation Server for instructions on using PXE to perform an update during installation. Note that this is an advanced procedure - do not attempt it unless other methods of performing a driver update fail.

Commands:
1.3. Installing GFS2 In addition to the packages required for the Red Hat High Availability Add-On, you must install the gfs2-utils package for GFS2 and the lvm2-cluster package for the Clustered Logical Volume Manager (CLVM). The lvm2-cluster and gfs2-utils packages are part of ResilientStorage channel, which must be enabled before installing the packages. You can use the following yum install command to install the Red Hat High Availability Add-On software packages: For general information on the Red Hat High Availability Add-On and cluster administration, see the Cluster Administration manual.

Commands:
yum install rgmanager lvm2-cluster gfs2-utils
A.13. numad numad is an automatic NUMA affinity management daemon. It monitors NUMA topology and resource usage within a system in order to dynamically improve NUMA resource allocation and management. Note that when numad is enabled, its behavior overrides the default behavior of automatic NUMA balancing. A.13.1. Using numad from the Command Line To use numad as an executable, just run: While numad runs, its activities are logged in /var/log/numad.log . It will run until stopped with the following command: Stopping numad does not remove the changes it has made to improve NUMA affinity. If system use changes significantly, running numad again will adjust affinity to improve performance under the new conditions. To restrict numad management to a specific process, start it with the following options. -p pid This option adds the specified pid to an explicit inclusion list. The process specified will not be managed until it meets the numad process significance threshold. -S 0 This sets the type of process scanning to 0 , which limits numad management to explicitly included processes. For further information about available numad options, refer to the numad man page: A.13.2. Using numad as a Service While numad runs as a service, it attempts to tune the system dynamically based on the current system workload. Its activities are logged in /var/log/numad.log . To start the service, run: To make the service persist across reboots, run: For further information about available numad options, refer to the numad man page: A.13.3. Pre-Placement Advice numad provides a pre-placement advice service that can be queried by various job management systems to provide assistance with the initial binding of CPU and memory resources for their processes. This pre-placement advice is available regardless of whether numad is running as an executable or a service. A.13.4. Using numad with KSM If KSM is in use on a NUMA system, change the value of the /sys/kernel/mm/ksm/merge_nodes parameter to 0 to avoid merging pages across NUMA nodes. Otherwise, KSM increases remote memory accesses as it merges pages across nodes. Furthermore, kernel memory accounting statistics can eventually contradict each other after large amounts of cross-node merging. As such, numad can become confused about the correct amounts and locations of available memory, after the KSM daemon merges many memory pages. KSM is beneficial only if you are overcommitting the memory on your system. If your system has sufficient free memory, you may achieve higher performance by turning off and disabling the KSM daemon.

Commands:
numad
numad -i 0
numad -S 0 -p pid
man numad
systemctl start numad.service
chkconfig numad on
man numad