mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Enabling NFS over RDMA on an NFS server Remote Direct Memory Access (RDMA) is a protocol that enables a client system to directly transfer data from the memory of a storage server into its own memory. This enhances storage throughput, decreases latency in data transfer between the server and client, and reduces CPU load on both ends. If both the NFS server and clients are connected over RDMA, clients can use NFSoRDMA to mount an exported directory. Prerequisites The NFS service is running and configured An InfiniBand or RDMA over Converged Ethernet (RoCE) device is installed on the server. IP over InfiniBand (IPoIB) is configured on the server, and the InfiniBand device has an IP address assigned. Procedure Install the rdma-core package: If the package was already installed, verify that the xprtrdma and svcrdma modules in the /etc/rdma/modules/rdma.conf file are uncommented: Optional: By default, NFS over RDMA uses port 20049. If you want to use a different port, set the rdma-port setting in the [nfsd] section of the /etc/nfs.conf file: Open the NFSoRDMA port in firewalld : Adjust the port numbers if you set a different port than 20049. Restart the nfs-server service: Verification On a client with InfiniBand hardware, perform the following steps: Install the following packages: Mount an exported NFS share over RDMA: If you set a port number other than the default (20049), pass port= <port_number> to the command: Verify that the share was mounted with the rdma option: Additional resources Configuring InfiniBand and RDMA networks

Commands:
dnf install rdma-core
NFS over RDMA client support xprtrdma NFS over RDMA server support svcrdma
rdma-port= <port>
firewall-cmd --permanent --add-port={ 20049 /tcp, 20049 /udp} firewall-cmd --reload
systemctl restart nfs-server
dnf install nfs-utils rdma-core
mount -o rdma server.example.com:/nfs/projects/ /mnt/
mount -o rdma,port=<port_number> server.example.com:/nfs/projects/ /mnt/
mount | grep " /mnt " server.example.com:/nfs/projects/ on /mnt type nfs (..., proto=rdma ,...)
3. Desktop Graphics Hardware Red Hat Enterprise Linux 6.1 provides a range of updates for graphics hardware. The driver for Intel Generation 6 Graphics on the Sandy Bridge processor is introduced in this release, providing fully accelerated 2D and 3D graphics on these devices. Additionally, this release introduces support for the Matrox MGA-G200ER graphics chipset. Red Hat Enterprise Linux 6.1 introduces the xorg-x11-drv-xgi video driver to support the XGI Z9S AND Z11 chipsets. The SIS driver that provided support for older XGI hardware is no longer being updated to support new hardware. Monitors that do not supply Extended Display Identification Data (EDID) to the operating system now have a default resolution of 1024 x 768 pixels. Network Manager NetworkManager is the desktop tool that is used to set up, configure and manage a wide range of network connection types. In Red Hat Enterprise Linux 6.1, NetworkManager has improved support for the configuration of Wi-Fi Protected Access (WPA) Enterprise and Internet Protocol version 6 (IPv6). Audio Red Hat Enterprise Linux 6.1 provides updated Advanced Linux Sound Architecture - High Definition Audio (ALSA-HDA) drivers.

Commands:
A.2.5. Cramer-Shoup Cryptosystem The Cramer-Shoup system is an asymmetric key encryption algorithm, and was the first efficient scheme proven to be secure against adaptive chosen ciphertext attack using standard cryptographic assumptions. Its security is based on the computational intractability (widely assumed, but not proved) of the decisional Diffie-Hellman assumption. Developed by Ronald Cramer and Victor Shoup in 1998, it is an extension of the ElGamal cryptosystem. In contrast to ElGamal, which is extremely malleable, Cramer-Shoup adds additional elements to ensure non-malleability even against a resourceful attacker. This non-malleability is achieved through the use of a collision-resistant hash function and additional computations, resulting in a ciphertext which is twice as large as in ElGamal. [21] [21] "Cramer-Shoup cryptosystem." Wikipedia. 24 February 2010 http://en.wikipedia.org/wiki/Cramer-Shoup_cryptosystem

Commands:
Common object reference OpenShift Container Platform 4.17 Reference guide common API objects Red Hat OpenShift Documentation Team

Commands:
<quantity> ::= <signedNumber><suffix>
(Note that <suffix> may be empty, from the "" case in <decimalSI>.)
(International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)
(Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)
type MyAPIObject struct { runtime.TypeMeta `json:",inline"` MyPlugin runtime.Object `json:"myPlugin"` }
type PluginA struct { AOption string `json:"aOption"` }
type MyAPIObject struct { runtime.TypeMeta `json:",inline"` MyPlugin runtime.RawExtension `json:"myPlugin"` }
type PluginA struct { AOption string `json:"aOption"` }
{ "kind":"MyAPIObject", "apiVersion":"v1", "myPlugin": { "kind":"PluginA", "aOption":"foo", }, }
25.4. Deadlock Detection A deadlock occurs when multiple processes or tasks wait for the other to release a mutually required resource. Deadlocks can significantly reduce the throughput of a system, particularly when multiple transactions operate against one key set. Red Hat JBoss Data Grid provides deadlock detection to identify such deadlocks. Deadlock detection is set to disabled by default. Report a bug 25.4.1. Enable Deadlock Detection Deadlock detection in Red Hat JBoss Data Grid is set to disabled by default but can be enabled and configured for each cache using the namedCache configuration element by adding the following: The spinDuration attribute defines how often lock acquisition is attempted within the maximum time allowed to acquire a particular lock (in milliseconds). Deadlock detection can only be applied to individual caches. Deadlocks that are applied on more than one cache cannot be detected by JBoss Data Grid. Report a bug

Commands:
<deadlockDetection enabled="true" spinDuration="100"/>
Chapter 1. Overview OpenStack Key Manager (barbican) is the secrets manager for Red Hat OpenStack Platform. You can use the barbican API and command line to centrally manage the certificates, keys, and passwords used by OpenStack services. Barbican currently supports the following use cases described in this guide: Symmetric encryption keys - used for Block Storage (cinder) volume encryption, ephemeral disk encryption, and Object Storage (swift) encryption, among others. Asymmetric keys and certificates - used for glance image signing and verification, among others. In this release, barbican offers integration with the Block Storage (cinder) and Compute (nova) components.

Commands:
15.2.2.3. Unresolved Dependency RPM packages can, essentially, depend on other packages, which means that they require other packages to be installed to run properly. If you try to install a package which has an unresolved dependency, output similar to the following is displayed: If you are installing a package from the Red Hat Enterprise Linux CD-ROM set, it usually suggest the package(s) needed to resolve the dependency. Find the suggested package(s) on the Red Hat Enterprise Linux CD-ROMs or from the Red Hat FTP site (or mirror), and add it to the command: If installation of both packages is successful, output similar to the following is displayed: If it does not suggest a package to resolve the dependency, you can try the --redhatprovides option to determine which package contains the required file. You need the rpmdb-redhat package installed to use this option. If the package that contains bar.so.2 is in the installed database from the rpmdb-redhat package, the name of the package is displayed: To force the installation anyway (which is not recommended since the package may not run correctly), use the --nodeps option.

Commands:
error: Failed dependencies: bar.so.2 is needed by foo-1.0-1 Suggested resolutions: bar-2.0.20-3.i386.rpm
-ivh foo-1.0-1.i386.rpm bar-2.0.20-3.i386.rpm
Preparing... ########################################### [100%] 1:foo ########################################### [ 50%] 2:bar ########################################### [100%]
-q --redhatprovides bar.so.2
bar-2.0.20-3.i386.rpm
Chapter 3. Accessing the high availability environment You can access and investigate specific HA nodes from the undercloud. Procedure In a running HA environment, log in to the undercloud. Change to the stack user: To access and investigate an undercloud node, get the IP address of the node from the undercloud: To log in to one of the overcloud nodes, run the following commands: Replace the name and IP address with the actual values from your deployment.

Commands:
sudo su - stack
(undercloud) USD source ~/stackrc (undercloud) USD openstack server list +-------+------------------------+---+----------------------+---+ | ID | Name |...| Networks |...| +-------+------------------------+---+----------------------+---+ | d1... | overcloud-controller-0 |...| ctlplane=*10.200.0.11* |...|
(undercloud) USD source ~/overcloudrc (overcloud) USD ssh [NODE_NAME]@[NODE_IP]
Chapter 4. Distribution selection Eclipse Temurin produces several distributions of Red Hat build of OpenJDK. Red Hat provides support for a subset of these distributions. All Eclipse Temurin distributions of Red Hat build of OpenJDK contain the JDK Flight Recorder (JFR) feature. This feature produces diagnostics and profiling data that can be consumed by other applications, such as JDK Mission Control (JMC). To help select a distribution that is right for your needs, see Platform Coverage for Red Hat Support of Eclipse Temurin (Red Hat Customer Portal) . Additional resources Temurin TM Supported Platforms (Adoptium) Eclipse Mission Control (Adoptium) Introduction to JDK Flight Recorder Red Hat build of OpenJDK Revised on 2024-05-09 16:45:52 UTC

Commands:
11.3.3.2. Global Options Each global option should be placed on a single line after a set action. daemon <seconds> - Specifies daemon-mode, where Fetchmail stays in the background. Replace <seconds> with the number of seconds Fetchmail is to wait before polling the server. postmaster - Specifies a local user to send mail to in case of delivery problems. syslog - Specifies the log file for errors and status messages. By default, this is /var/log/maillog .

Commands:
13.6. Welcome Screen and Language Selection The first screen of the installation program is the Welcome to Red Hat Enterprise Linux screen. Here you select the language that Anaconda will use for the rest of the installation. This selection will also become the default for the installated system, unless changed later. In the left panel, select your language of choice, for example English . Then you can select a locale specific to your region in the right panel, for example English (United States) . Note One language is pre-selected by default on top of the list. If network access is configured at this point (for example, if you booted from a network server instead of local media), the pre-selected language will be determined based on automatic location detection using the GeoIP module. Alternatively, type your preferred language into the search box as shown below. Once you have made your selection, click the Continue button to proceed to the Installation Summary screen. Figure 13.3. Language Configuration After you click the Continue button, the unsupported hardware dialog may appear. This happens if you are using hardware that the kernel does not support.

Commands:
Chapter 2. Accessing Red Hat Gluster Storage using Amazon Web Services Red Hat Gluster Storage for Public Cloud packages glusterFS as an Amazon Machine Image (AMI) for deploying scalable network attached storage (NAS) in the Amazon Web Services (AWS) public cloud. This storage server provides a highly available, scalable, virtualized, and centrally managed pool of storage for Amazon users. Red Hat Gluster Storage for Public Cloud provides highly available storage within AWS. Synchronous n-way replication across AWS Availability Zones provides high availability within an AWS region. Asynchronous geo-replication provides continuous data replication to ensure high availability across the AWS regions. The glusterFS global namespace capability aggregates disk and memory resources into a unified storage volume that is abstracted from the physical hardware. The following diagram illustrates AWS integration with Red Hat Gluster Storage: Figure 2.1. Amazon Web Services integration architecture Important The following features are not supported on Amazon Web Services: NFS and CIFS High Availability Red Hat Gluster Storage Web Administration 2.1. Accessing Red Hat Gluster Storage as an Amazon Machine Image For information on obtaining access to Red Hat Gluster Storage as an Amazon Machine Image (AMI), see the following resources: https://access.redhat.com/knowledge/articles/145693 https://access.redhat.com/solutions/314993

Commands:
Part II. Technology Previews This chapter provides a list of all available Technology Previews in Red Hat Enterprise Linux 6.9. Technology Preview features are currently not supported under Red Hat Enterprise Linux subscription services, may not be functionally complete, and are generally not suitable for production use. However, these features are included as a customer convenience and to provide the feature with wider exposure. Customers may find these features useful in a non-production environment. Customers are also free to provide feedback and functionality suggestions for a Technology Preview feature before it becomes fully supported. Errata will be provided for high-severity security issues. During the development of a Technology Preview feature, additional components may become available to the public for testing. It is the intention of Red Hat clustering to fully support Technology Preview features in a future release. For information on Red Hat scope of support for Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/ .

Commands:
Chapter 10. Configuring the node port service range As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports. The default port range is 30000-32767 . You can never reduce the port range, even if you first expand it beyond the default range. 10.1. Prerequisites Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to 30000-32900 , the inclusive port range of 32768-32900 must be allowed by your firewall or packet filtering configuration. 10.2. Expanding the node port range You can expand the node port range for the cluster. Prerequisites Install the OpenShift CLI ( oc ). Log in to the cluster with a user with cluster-admin privileges. Procedure To expand the node port range, enter the following command. Replace <port> with the largest port number in the new range. USD oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }' Tip You can alternatively apply the following YAML to update the node port range: apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>" Example output network.config.openshift.io/cluster patched To confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply. USD oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]' Example output "service-node-port-range":["30000-33000"] 10.3. Additional resources Configuring ingress cluster traffic using a NodePort Network [config.openshift.io/v1 ] Service [core/v1 ]

Commands:
oc patch network.config.openshift.io cluster --type=merge -p '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
network.config.openshift.io/cluster patched
oc get configmaps -n openshift-kube-apiserver config -o jsonpath="{.data['config\.yaml']}" | grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
"service-node-port-range":["30000-33000"]
Chapter 4. Testing the setup Before the HA cluster setup is put into production, it needs to be thoroughly tested to verify that everything works as expected and also to allow the operators to get experience with how the HA cluster will behave in certain situations and how to bring the setup back to a healthy state in case a failure occurs. At least the following tests should be carried out: Perform a manual move of the primary SAP HANA instance via HA cluster commands. Expected result: a takeover should be triggered on the SAP HANA side, promoting the secondary SAP HANA instance to become the new primary SAP HANA instance. Depending on the configuration of the AUTOMATED_REGISTER parameter of the SAPHana resource, the HA cluster will either register the former primary instance, as the new secondary automatically, or an operator will have to determine what should happen with the former primary instance Crash the HA cluster node where the primary SAP HANA instance is running. Expected result: the HA cluster node should be fenced and a takeover should be triggered on the SAP HANA side, promoting the secondary SAP HANA instance to become the new primary SAP HANA instance. Depending on the configuration of the AUTOMATED_REGISTER parameter of the SAPHana resource, the HA cluster will either register the former primary instance as the new secondary automatically, or an operator will have to determine what should happen with the former primary instance. Manually stop primary SAP HANA instance outside of HA cluster. Expected result: a takeover should be triggered on the SAP HANA side, promoting the secondary SAP HANA instance to become the new primary SAP HANA instance. Depending on the configuration of the AUTOMATED_REGISTER parameter of the SAPHana resource, the HA cluster will either register the former primary instance as the new secondary automatically, or an operator will have to determine what should happen with the former primary instance. Crash the node where the secondary SAP HANA instance is running. Expected result: the HA cluster node should be fenced and the secondary SAP HANA instance should be started when the HA cluster node is back online and SAP HANA System Replication should resume. Manually stop the secondary SAP HANA instance outside of HA cluster Expected result: the secondary SAP HANA instance should be restarted by the HA cluster Disable the network connection used by SAP HANA System Replication Expected result: the HA cluster should detect that a failure of SAP HANA System Replication has occurred, but should keep the SAP HANA instances running on both nodes

Commands:
Chapter 4. Downloading Red Hat build of OptaPlanner examples You can download the Red Hat build of OptaPlanner examples as a part of the {PRODUCTPAM} add-ons package available on the Red Hat Customer Portal. Procedure Navigate to the Software Downloads page in the Red Hat Customer Portal (login required), and select the product and version from the drop-down options: Product: Process Automation Manager Version: 7.13.5 Download Red Hat Process Automation Manager 7.13 Add Ons . Extract the rhpam-7.13.5-add-ons.zip file. The extracted add-ons folder contains the rhpam-7.13.5-planner-engine.zip file. Extract the rhpam-7.13.5-planner-engine.zip file. Result The extracted rhpam-7.13.5-planner-engine directory contains example source code under the following subdirectories: examples/sources/src/main/java/org/optaplanner/examples examples/sources/src/main/resources/org/optaplanner/examples 4.1. Running OptaPlanner examples Red Hat build of OptaPlanner includes several examples that demonstrate a variety of planning use cases. Download and use the examples to explore different types of planning solutions. Prerequisites You have downloaded and extracted the examples as described in Chapter 4, Downloading Red Hat build of OptaPlanner examples . Procedure To run the examples, in the rhpam-7.13.5-planner-engine/examples directory enter one of the following commands: Linux or Mac: Windows: The OptaPlanner Examples window opens. Select an example to run that example. Note Red Hat build of OptaPlanner has no GUI dependencies. It runs just as well on a server or a mobile JVM as it does on the desktop. 4.2. Running the Red Hat build of OptaPlanner examples in an IDE (IntelliJ, Eclipse, or Netbeans) If you use an integrated development environment (IDE), such as IntelliJ, Eclipse, or Netbeans, you can run your downloaded OptaPlanner examples within your development environment. Prerequisites You have downloaded and extracted the OptaPlanner examples as described in Chapter 4, Downloading Red Hat build of OptaPlanner examples . Procedure Open the OptaPlanner examples as a new project: For IntelliJ or Netbeans, open examples/sources/pom.xml as the new project. The Maven integration guides you through the rest of the installation. Skip the rest of the steps in this procedure. For Eclipse, open a new project for the /examples/binaries directory, located under the rhpam-7.13.5-planner-engine directory. Add all the JAR files that are in the binaries directory to the classpath, except for the examples/binaries/optaplanner-examples-7.67.0.Final-redhat-00024.jar file. Add the Java source directory src/main/java and the Java resources directory src/main/resources , located under the rhpam-7.13.5-planner-engine/examples/sources/ directory. Create a run configuration: Main class: org.optaplanner.examples.app.OptaPlannerExamplesApp VM parameters (optional): -Xmx512M -server -Dorg.optaplanner.examples.dataDir=examples/sources/data Working directory: examples/sources Run the run configuration.

Commands:
./runExamples.sh
runExamples.bat