mtpti5iD/redhat-docs_dataset huggingface dataset:
19.3. Network Data traffic Network becomes a bottleneck as and when number of storage nodes increase. By adding a 10GbE or faster network for data traffic, you can achieve faster per node performance. Jumbo frames must be enabled at all levels, that is, client, Red Hat Gluster Storage node, and ethernet switch levels. MTU of size N+208 must be supported by ethernet switch where N=9000. We recommend you to have a separate network for management and data traffic when protocols like NFS /CIFS are used instead of native client. Preferred bonding mode for Red Hat Gluster Storage client is mode 6 (balance-alb), this allows client to transmit writes in parallel on separate NICs much of the time.

Commands:
8.129. numad 8.129.1. RHBA-2013:1705 - numad bug fix and enhancement update Updated numad packages that fix two bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The numad packages provide a daemon for NUMA (Non-Uniform Memory Architecture) systems, monitors NUMA characteristics and manages placement of processes and memory to minimize memory latency. The packages also provide an interface that can be used to query the numad daemon for the best manual placement of an application. Bug Fixes BZ# 987563 When all CPUs were busy, the numad daemon was too reluctant to balance processes across nodes even though it would have resulted in significantly better application and system performance. With this update, numad is more aggressive about moving processes even when all CPUs are busy. As a result, overall system performance has improved significantly. BZ# 987559 Previously, it was not possible to set the system's hugepage "scan_sleep_millisecs" parameter. As a consequence, NUMA performance was damaged when process memory was migrated across nodes. The underlying code has been changed to accept the new "-H" option to specify "scan_sleep_millisecs", thus fixing the bug. The user can now set the value to fine-tune the numad's performance. Enhancement BZ# 913546 A configuration file for the logrotate tool has been added to be fully supported by Red Hat Enterprise Linux 6. All users of numad are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 4. Advisories related to this release The following advisories are issued to document bug fixes and CVE fixes included in this release: RHSA-2025:0421 RHSA-2025:0422 RHSA-2025:0423 RHSA-2025:0424 RHSA-2025:0425 Revised on 2025-01-30 11:26:57 UTC

Commands:
4.14. autotrace 4.14.1. RHBA-2011:1168 - autotrace bug fix update Updated autotrace packages that fix one bug are now available for Red Hat Enterprise Linux 6. AutoTrace is a program for converting bitmaps to vector graphics. Supported input formats include BMP, TGA, PNM, PPM, and any format supported by ImageMagick, whereas output can be produced in PostScript, SVG, xfig, SWF, and others. Bug Fix BZ# 658057 When installing autotrace-devel multilib RPM packages from the optional repository, file conflicts between these packages appeared, causing the installation transaction to abort. This problem has been fixed and the installation transaction now proceeds without conflicts. All users of autotrace are advised to upgrade to these updated packages, which resolve this issue.

Commands:
Chapter 2. Start, stop, and restart automation controller Automation controller ships with an administrator utility script, automation-controller-service . The script can start, stop, and restart all automation controller services running on the current single automation controller node. The script includes the message queue components and the database if it is an integrated installation. External databases must be explicitly managed by the administrator. You can find the services script in /usr/bin/automation-controller-service , which can be invoked with the following command: root@localhost:~USD automation-controller-service restart Note In clustered installs, the automation-controller-service restart does not include PostgreSQL as part of the services that are restarted. This is because it exists external to automation controller, and PostgreSQL does not always need to be restarted. Use systemctl restart automation-controller to restart services on clustered environments instead. You must also restart each cluster node for certain changes to persist as opposed to a single node for a localhost install. For more information on clustered environments, see the Clustering section. You can also invoke the services script using distribution-specific service management commands. Distribution packages often provide a similar script, sometimes as an init script, to manage services. For more information, see your distribution-specific service management system. Important When running automation controller in a container, do not use the automation-controller-service script. Restart the pod using the container environment instead.

Commands:
root@localhost:~USD automation-controller-service restart
2.2.3. Securing NIS The Network Information Service ( NIS ) is an RPC service, called ypserv , which is used in conjunction with portmap and other related services to distribute maps of user names, passwords, and other sensitive information to any computer claiming to be within its domain. A NIS server is comprised of several applications. They include the following: /usr/sbin/rpc.yppasswdd - Also called the yppasswdd service, this daemon allows users to change their NIS passwords. /usr/sbin/rpc.ypxfrd - Also called the ypxfrd service, this daemon is responsible for NIS map transfers over the network. /usr/sbin/yppush - This application propagates changed NIS databases to multiple NIS servers. /usr/sbin/ypserv - This is the NIS server daemon. NIS is somewhat insecure by today's standards. It has no host authentication mechanisms and transmits all of its information over the network unencrypted, including password hashes. As a result, extreme care must be taken when setting up a network that uses NIS. This is further complicated by the fact that the default configuration of NIS is inherently insecure. It is recommended that anyone planning to implement a NIS server first secure the portmap service as outlined in Section 2.2.2, "Securing Portmap" , then address the following issues, such as network planning. 2.2.3.1. Carefully Plan the Network Because NIS transmits sensitive information unencrypted over the network, it is important the service be run behind a firewall and on a segmented and secure network. Whenever NIS information is transmitted over an insecure network, it risks being intercepted. Careful network design can help prevent severe security breaches.

Commands:
20.16.10. Input Devices Input devices allow interaction with the graphical framebuffer in the guest virtual machine virtual machine. When enabling the framebuffer, an input device is automatically provided. It may be possible to add additional devices explicitly, for example, to provide a graphics tablet for absolute cursor movement. To specify the input devices configuration settings, use a management tool to make the following changes to the domain XML: ... <devices> <input type='mouse' bus='usb'/> </devices> ... Figure 20.54. Input devices The <input> element has one mandatory attribute: type which can be set to: mouse or tablet . The latter provides absolute cursor movement, while the former uses relative movement. The optional bus attribute can be used to refine the exact device type and can be set to: xen (paravirtualized), ps2 , and usb . The input element has an optional sub-element <address> , which can tie the device to a particular PCI slot, as documented above.

Commands:
<devices> <input type='mouse' bus='usb'/> </devices>
Chapter 4. Setting up the test environment The first step towards certifying your product is setting up the environment where you can run the tests. The test environment consists of only the Undercloud node. All the mandatory tests that verify the system configuration required for bare metal certification run on the Undercloud node. Important If you prefer using Cockpit instead of the command line for baremetal testing, you must set up the Cockpit first. See Configuring the systems and running tests by using Cockpit for instructions. 4.1. Setting up the Undercloud node Prerequisites You have installed RHOSP on the system based on the supported RHEL version, as applicable. Ensure to use RHOSP Director for installation, as it is the supported toolset for installing and managing RHOSP in production. The corresponding supported versions are as follows: RHOSP version Supported RHEL version RHEL 16.0 8.1 RHEL 16.1 8.2 RHEL 16.2 8.4 RHEL 17.0 9.0 RHEL 17.1 9.2 and 9.4 Ensure that the RSA private key file is in PEM format. See RHOSP 17.1 Configuration Reference document for more information. Procedure Use your RHN credentials to register your system using Red Hat Subscription Management: Display the list of available subscriptions for your system: Search for the subscription that provides the Red Hat Certification (for RHEL Server) repository and make a note of the subscription and its Pool ID. Attach the subscription to your system: Replace the pool_ID with the Pool ID of the subscription. Subscribe to the Red Hat Certification channel: On RHEL 8: Replace HOSTTYPE with the system architecture. To find out the system architecture, run Example: On RHEL 9: Replace HOSTTYPE with the system architecture. To find out the system architecture, run Example: Install the certification RPMs. Only on RHEL 9 Install OpenStack test suite package: 4.2. Configuring Bare Metal See Bare Metal Provisioning service (ironic) functionality for installing, configuring, and using the Bare Metal service in the undercloud of a Red Hat OpenStack Platform environment. 4.3. Validating Bare Metal configuration Procedure You must validate that Bare Metal is working prior to starting the certification process. To see the registered nodes and their current status, follow the Troubleshooting node provisioning chapter described in the Installing and managing Red Hat OpenStack Platform with director guide.

Commands:
subscription-manager register
subscription-manager list --available*
subscription-manager attach --pool= <pool_ID >
subscription-manager repos --enable=cert-1-for-rhel-8- <HOSTTYPE> -rpms
uname -m
subscription-manager repos --enable=cert-1-for-rhel-8-x86_64-rpms
subscription-manager repos --enable=cert-1-for-rhel-9- <HOSTTYPE> -rpms
uname -m
subscription-manager repos --enable=cert-1-for-rhel-9-x86_64-rpms
yum install redhat-certification
install redhat-certification-baremetal
3.4. irqbalance irqbalance is a command line tool that distributes hardware interrupts across processors to improve system performance. It runs as a daemon by default, but can be run once only with the --oneshot option. The following parameters are useful for improving performance. --powerthresh Sets the number of CPUs that can idle before a CPU is placed into powersave mode. If more CPUs than the threshold are more than 1 standard deviation below the average softirq workload and no CPUs are more than one standard deviation above the average, and have more than one irq assigned to them, a CPU is placed into powersave mode. In powersave mode, a CPU is not part of irq balancing so that it is not woken unnecessarily. --hintpolicy Determines how irq kernel affinity hinting is handled. Valid values are exact (irq affinity hint is always applied), subset (irq is balanced, but the assigned object is a subset of the affinity hint), or ignore (irq affinity hint is ignored completely). --policyscript Defines the location of a script to execute for each interrupt request, with the device path and irq number passed as arguments, and a zero exit code expected by irqbalance . The script defined can specify zero or more key value pairs to guide irqbalance in managing the passed irq. The following are recognized as valid key value pairs. ban Valid values are true (exclude the passed irq from balancing) or false (perform balancing on this irq). balance_level Allows user override of the balance level of the passed irq. By default the balance level is based on the PCI device class of the device that owns the irq. Valid values are none , package , cache , or core . numa_node Allows user override of the NUMA node that is considered local to the passed irq. If information about the local node is not specified in ACPI, devices are considered equidistant from all nodes. Valid values are integers (starting from 0) that identify a specific NUMA node, and -1 , which specifies that an irq should be considered equidistant from all nodes. --banirq The interrupt with the specified interrupt request number is added to the list of banned interrupts. You can also use the IRQBALANCE_BANNED_CPUS environment variable to specify a mask of CPUs that are ignored by irqbalance . For further details, see the man page:

Commands:
man irqbalance
Chapter 4. Planning provisioning for bare-metal data plane nodes You can use pre-provisioned nodes or unprovisioned, bare-metal nodes on the Red Hat OpenStack Services on OpenShift (RHOSO) data plane: Pre-provisioned node: You have used your own tooling to install the operating system on the node before adding it to the data plane. Unprovisioned node: The node does not have an operating system installed before you add it to the data plane. The node is provisioned by using the Red Hat OpenShift Container Platform (RHOCP) Cluster Baremetal Operator (CBO) as part of the data plane creation and deployment process. The CBO is a core RHOCP cluster Operator that is enabled by default on all platforms. A RHOSO environment can support all the remote hardware management protocol technologies and boot methods that Metal 3 supports. For information about the supported hardware, see Supported hardware in the Metal 3 user-guide . The platform on which you installed your RHOCP cluster limits the technologies and boot methods available to your RHOSO deployment for provisioning bare-metal data plane nodes. Therefore, you must plan your RHOSO deployment to ensure that the technologies and boot methods you require for provisioning bare-metal data plane nodes are supported on your RHOCP cluster platform. For more information about installing RHOCP on a specific platform, see the installation guide for your platform in the RHOCP Install guide. You require a Provisioning custom resource (CR) for node provisioning. The Provisioning CR is available on RHOCP clusters with the platform parameter set to baremetal in the install-config.yaml file. For all other platforms, contact the Red Hat Customer Experience and Engagement team for assistance. Note Provision bare-metal data plane nodes with virtual media rather than with iPXE boot, because iPXE boot might not be available in your RHOCP cluster. 4.1. The Bare Metal Operator (BMO) Provisioning bare-metal nodes on the data plane is supported with the Red Hat OpenShift Container Platform (RHOCP) Cluster Baremetal Operator (CBO). The CBO is a core cluster Operator that is enabled by default on all platforms. The CBO deploys the components required to provision bare-metal nodes within the RHOCP cluster, including the Bare Metal Operator (BMO) and Ironic containers. The BMO manages the available hosts on clusters and performs the following operations: Inspects node hardware details and reports them to the corresponding BareMetalHost CR. This includes information about CPUs, RAM, disks, and NICs. Provisions nodes with a specific image. Cleans node disk contents before and after provisioning. For more information about the Bare Metal Operator and how to configure a BareMetalHost CR, see About the Bare Metal Operator in the RHOCP Postinstallation configuration guide.

Commands:
8.5. Repairing an XFS File System To repair an XFS file system, use xfs_repair : The xfs_repair utility is highly scalable and is designed to repair even very large file systems with many inodes efficiently. Unlike other Linux file systems, xfs_repair does not run at boot time, even when an XFS file system was not cleanly unmounted. In the event of an unclean unmount, xfs_repair simply replays the log at mount time, ensuring a consistent file system. Warning The xfs_repair utility cannot repair an XFS file system with a dirty log. To clear the log, mount and unmount the XFS file system. If the log is corrupt and cannot be replayed, use the -L option ("force log zeroing") to clear the log, that is, xfs_repair -L /dev/device . Be aware that this may result in further corruption or data loss. For more information about repairing an XFS file system, refer to man xfs_repair .

Commands:
xfs_repair /dev/device
Chapter 14. Integration with the Spring Framework JBoss Data Grid allows users to define a Spring Cache provider, providing applications a method of easily adding caching support, and allowing users familiar with Spring's programming model a way to have caching fulfilled by JBoss Data Grid. Note JSR-107 (JCache) annotations are only supported in Spring 4. Important Spring 3 has been deprecated in JBoss Data Grid 6.6.0, and is expected to be removed in subsequent versions. Report a bug 14.1. Defining the Spring Maven Dependency The Spring module is bundled separately from the Library and Remote Client-Server dependencies. The following Maven configuration should be used, corresponding with the version of Spring in use. Spring 4 Example 14.1. pom.xml for Spring 4 in Library Mode Example 14.2. pom.xml for Spring 4 in Remote Client-Server Mode Spring 3 Example 14.3. pom.xml for Spring 3 (for both Library and Remote Client-Server Mode) Report a bug

Commands:
<dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-spring4-embedded</artifactId> <version>USD{infinispan.version}</version> </dependency>
<dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-spring4-remote</artifactId> <version>USD{infinispan.version}</version> </dependency>
<dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-spring3</artifactId> <version>USD{infinispan.version}</version> </dependency>
Chapter 19. Directory Server in Red Hat Enterprise Linux IdM schema replications from Red Hat Enterprise Linux 7 to 6.9 fail Identity Management (IdM) in Red Hat Enterprise Linux 6.9 uses a different schema definition in the nsEncryptionConfig object class than IdM on Red Hat Enterprise Linux 7.3. Because the schema learning mechanism is unable to merge definitions, schema replications between servers fail. As a consequence, mechanisms relying on the schema can fail. For example, schema violations and plug-in failures can occur, replication can fail, and access control instructions (ACI) can be ignored. In an upcoming Red Hat Enterprise Linux 7.3 update, the nsTLS10 , nsTLS11 , and nsTLS12 attributes will be added to the list of allowed attributes in the nsEncryptionConfig object class, and as a consequence, mechanisms relying on the schema no longer fails in the described scenario. (BZ# 1404443 )

Commands:
Chapter 17. Guided rules Guided rules are business rules that you create in a UI-based guided rules designer in Business Central that leads you through the rule-creation process. The guided rules designer provides fields and options for acceptable input based on the data objects for the rule being defined. The guided rules that you define are compiled into Drools Rule Language (DRL) rules as with all other rule assets. All data objects related to a guided rule must be in the same project package as the guided rule. Assets in the same package are imported by default. After you create the necessary data objects and the guided rule, you can use the Data Objects tab of the guided rules designer to verify that all required data objects are listed or to import other existing data objects by adding a New item . 17.1. Viewing the Mortgage_Process business rules The goal of this chapter is to introduce you to the predefined business rules for the Mortgage_Process project. For this tutorial, you do not create and define the business rules. Instead, review the WHEN and THEN rules that are already defined in the Mortgage_Process sample project's preconfigured business rules. For information about creating guided business rules, see Designing a decision service using guided rules . 17.1.1. Viewing the Validate Down Payment guided rule Review the WHEN and THEN rules so that you understand how the conditions are set and used later when you run the process. Procedure Click Menu Design Projects , and click Mortgage_Process . From the asset list, click the right arrow to view the second page of the asset list and click the Validate Down Payment guided rule. Review the Validate Down Payment guided rule's WHEN and THEN conditions and values. 17.1.2. Viewing the RetractValidationErr guided rule Review the WHEN and THEN rules so that you understand how the conditions are set and used later when you run the process. Procedure Click Menu Design Projects , and click Mortgage_Process . From the asset list, click the right arrow to view the second page of the asset list and click the RetractValidationErr guided rule. Review the RetractValidationErr guided rule's WHEN and THEN conditions and values.

Commands:
Chapter 10. Enabling and configuring Data Grid OpenTelemetry tracing Data Grid generates tracing spans compatible with the OpenTelemetry standard, allowing you to export, visualize, and analyze tracing data related to the most important cache operations. 10.1. Enabling Data Grid tracing Configure OpenTelemetry tracing, to enable monitoring and tracing of cache operations. Procedure Pass the system properties to Data Grid Server at startup. Use -D<property-name>=<property-value> arguments like in the following example: steps To apply any configuration changes, stop the server and repeat the procedure. Tracing configuration Data Grid applies the tracing configuration globally to all caches. tracing.properties 1 Enables tracing for all cache operations. 2 Sets the exporter format. The OTLP (OpenTelemetry protocol) exporter is the recommended format to export tracing data. 3 Specifies the service name associated with the generated tracing spans. The default name is Infinispan Server . 4 Specifies the endpoint URL of the OpenTelemetry collector where the tracing data is sent. 4318 is typically the http/protobuf OTLP standard port. Additional resources OpenTelemetry SDK Autoconfigure Tracing data format The Data Grid Server, by default, exports tracing data using the OTLP http/protobuf protocol. tracing.properties To use a different protocol, you must copy JAR files or dependencies to the USDISPN_HOME/server/lib directory of your Data Grid Server installation.

Commands:
bin/server.sh -Dinfinispan.tracing.enabled=true -Dotel.traces.exporter=otlp -Dotel.service.name=my-infinispan-server -Dotel.exporter.otlp.endpoint=http://otlp-collector-host:4318
infinispan.tracing.enabled = true 1 otel.traces.exporter = otlp 2 otel.service.name = <my-infinispan-server> 3 otel.exporter.otlp.endpoint = http://otlp-collector-host:4318 4
otel.exporter.otlp.protocol = http/protobuf
3.4. Additional Resources This section includes various resources that can be used to learn more about the Red Hat Enterprise Linux-specific subject matter discussed in this chapter. 3.4.1. Installed Documentation The following resources are installed in the course of a typical Red Hat Enterprise Linux installation and can help you learn more about the subject matter discussed in this chapter. vmstat(8) man page -- Learn how to display a concise overview of process, memory, swap, I/O, system, and CPU utilization. iostat(1) man page -- Learn how to display CPU and I/O statistics. sar(1) man page -- Learn how to produce system resource utilization reports. sadc(8) man page -- Learn how to collect system utilization data. sa1(8) man page -- Learn about a script that runs sadc periodically. top(1) man page -- Learn how to display CPU utilization and process-level statistics.

Commands: