mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Using the Load Balancer Add-On with the High Availability Add-On You can use the Load Balancer Add-On with the High Availability Add-On to deploy a high-availability e-commerce site that provides load balancing, data integrity, and application availability. The configuration in Figure A.1, "Load Balancer Add-On with a High Availability Add-On" represents an e-commerce site used for online merchandise ordering through a URL. Client requests to the URL pass through the firewall to the active LVS load-balancing router, which then forwards the requests to one of the Web servers. The High Availability Add-On nodes serve dynamic data to the Web servers, which forward the data to the requesting client. Figure A.1. Load Balancer Add-On with a High Availability Add-On Serving dynamic Web content with Load Balancer Add-On requires a three-tier configuration (as shown in Figure A.1, "Load Balancer Add-On with a High Availability Add-On" ). This combination of Load Balancer Add-On and High Availability Add-On allows for the configuration of a high-integrity, no-single-point-of-failure e-commerce site. The High Availability Add-On can run a high-availability instance of a database or a set of databases that are network-accessible to the Web servers. A three-tier configuration is required to provide dynamic content. While a two-tier Load Balancer Add-On configuration is suitable if the Web servers serve only static Web content (consisting of small amounts of infrequently changing data), a two-tier configuration is not suitable if the Web servers serve dynamic content. Dynamic content could include product inventory, purchase orders, or customer databases, which must be consistent on all the Web servers to ensure that customers have access to up-to-date and accurate information. Each tier provides the following functions: First tier - LVS router performing load-balancing to distribute Web requests. Second tier - A set of Web servers to serve the requests. Third tier - A High Availability Add-On to serve data to the Web servers. In a Load Balancer Add-On configuration like the one in Figure A.1, "Load Balancer Add-On with a High Availability Add-On" , client systems issue requests on the World Wide Web. For security reasons, these requests enter a Web site through a firewall, which can be a Linux system serving in that capacity or a dedicated firewall device. For redundancy, you can configure firewall devices in a failover configuration. Behind the firewall is an LVS router that provides load balancing, which can be configured in an active-standby mode. The active load-balancing router forwards the requests to the set of Web servers. Each Web server can independently process an HTTP request from a client and send the response back to the client. The Load Balancer Add-On enables you to expand a Web site's capacity by adding Web servers behind the LVS router; the LVS router performs load balancing across a wider set of Web servers. In addition, if a Web server fails, it can be removed; Load Balancer Add-On continues to perform load balancing across a smaller set of Web servers.

Commands:
Chapter 89. JarArtifact schema reference Used in: Plugin Property Description url URL of the artifact which will be downloaded. AMQ Streams does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for jar , zip , tgz and other artifacts. Not applicable to the maven artifact type. string sha512sum SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the maven artifact type. string insecure By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to true , all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure. boolean type Must be jar . string

Commands:
5.121. java-1.6.0-ibm 5.121.1. RHSA-2012:1466 - Critical: java-1.6.0-ibm security update Updated java-1.6.0-ibm packages that fix several security issues are now available for Red Hat Enterprise Linux 5 and 6 Supplementary. The Red Hat Security Response Team has rated this update as having critical security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. IBM Java SE version 6 includes the IBM Java Runtime Environment and the IBM Java Software Development Kit. Security Fix CVE-2012-0547 , CVE-2012-1531 , CVE-2012-1532 , CVE-2012-1533 , CVE-2012-1682 , CVE-2012-3143 , CVE-2012-3159 , CVE-2012-3216 , CVE-2012-4820 , CVE-2012-4822 , CVE-2012-4823 , CVE-2012-5068 , CVE-2012-5069 , CVE-2012-5071 , CVE-2012-5072 , CVE-2012-5073 , CVE-2012-5075 , CVE-2012-5079 , CVE-2012-5081 , CVE-2012-5083 , CVE-2012-5084 , CVE-2012-5089 This update fixes several vulnerabilities in the IBM Java Runtime Environment and the IBM Java Software Development Kit. Detailed vulnerability descriptions are linked from the IBM Security alerts page . All users of java-1.6.0-ibm are advised to upgrade to these updated packages, containing the IBM Java SE 6 SR12 release. All running instances of IBM Java must be restarted for the update to take effect. 5.121.2. RHSA-2012:1238 - Critical: java-1.6.0-ibm security update Updated java-1.6.0-ibm packages that fix several security issues are now available for Red Hat Enterprise Linux 5 and 6 Supplementary. The Red Hat Security Response Team has rated this update as having critical security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. IBM Java SE version 6 includes the IBM Java Runtime Environment and the IBM Java Software Development Kit. Security Fix CVE-2012-0551 , CVE-2012-1713 , CVE-2012-1716 , CVE-2012-1717 , CVE-2012-1718 , CVE-2012-1719 , CVE-2012-1721 , CVE-2012-1722 , CVE-2012-1725 This update fixes several vulnerabilities in the IBM Java Runtime Environment and the IBM Java Software Development Kit. Detailed vulnerability descriptions are linked from the IBM Security alerts page . All users of java-1.6.0-ibm are advised to upgrade to these updated packages, containing the IBM Java SE 6 SR11 release. All running instances of IBM Java must be restarted for the update to take effect.

Commands:
14.5.17. Using blockresize to Change the Size of a Domain Path blockresize can be used to re-size a block device of a domain while the domain is running, using the absolute path of the block device which also corresponds to a unique target name ( <target dev="name"/> ) or source file ( <source file="name"/> ). This can be applied to one of the disk devices attached to domain (you can use the command domblklist to print a table showing the brief information of all block devices associated with a given domain). Note Live image re-sizing will always re-size the image, but may not immediately be picked up by guests. With recent guest kernels, the size of virtio-blk devices is automatically updated (older kernels require a guest reboot). With SCSI devices, it is required to manually trigger a re-scan in the guest with the command, echo > /sys/class/scsi_device/0:0:0:0/device/rescan . In addition, with IDE it is required to reboot the guest before it picks up the new size. Run the following command: blockresize [domain] [path size] where: Domain is the unique target name or source file of the domain whose size you want to change Path size is a scaled integer which defaults to KiB (blocks of 1024 bytes) if there is no suffix. You must use a suffix of "B" to for bytes.

Commands:
Chapter 1. Red Hat OpenStack Platform hyperconverged infrastructure Red Hat OpenStack Platform (RHOSP) hyperconverged infrastructures (HCI) consist of hyperconverged nodes. Services are colocated on these hyperconverged nodes for optimized resource usage. In a RHOSP HCI, the Compute and storage services are colocated on hyperconverged nodes. You can deploy an overcloud with only hyperconverged nodes, or a mixture of hyperconverged nodes with normal Compute and Ceph Storage nodes. Note You must use Red Hat Ceph Storage as the storage provider. Tip Use ceph-ansible 3.2 and later to automatically tune Ceph memory settings. Use BlueStore as the back end for HCI deployments, to make use of the BlueStore memory handling features. This document describes how to deploy HCI on an overcloud, and integrate with other features in your overcloud, such as Network Function Virtualization. This document also covers how to ensure optimal performance of both Compute and Ceph Storage services on hyperconverged nodes. 1.1. Prerequisites You have deployed the undercloud. For instructions about how to deploy the undercloud, see the Director Installation and Usage guide. Your environment can provision nodes that meet Compute and Ceph Storage requirements. For more information, see Basic Overcloud Deployment in the Director Installation and Usage guide. You have registered all nodes in your environment. For more information, see Registering Nodes in the Deploying an Overcloud with Containerized Red Hat Ceph guide. You have tagged all nodes in your environment. For more information, see Manually Tagging the Nodes in the Deploying an Overcloud with Containerized Red Hat Ceph guide. You have cleaned the disks on nodes that you plan to use for Compute and Ceph OSD services. For more information, see Cleaning Ceph Storage Node Disks in the Deploying an Overcloud with Containerized Red Hat Ceph guide. You have prepared your overcloud nodes for registration with the Red Hat Content Delivery Network or a Red Hat Satellite server. For more information, see Ansible-based Overcloud Registration in the Advanced Overcloud Customization guide. 1.2. References For more detailed information about the Red Hat OpenStack Platform (RHOSP), see the following guides: Director Installation and Usage : This guide provides guidance on the end-to-end deployment of a RHOSP environment, both undercloud and overcloud. Advanced Overcloud Customization : This guide describes how to configure advanced RHOSP features through the director, such as how to use custom roles. Deploying an Overcloud with Containerized Red Hat Ceph : This guide describes how to deploy an overcloud that uses Red Hat Ceph Storage as a storage provider. Networking Guide : This guide provides details on RHOSP networking tasks. Hyper-converged Red Hat OpenStack Platform 10 and Red Hat Ceph Storage 2 : This guide provides a reference architecture that describes how to deploy an environment featuring HCI on very specific hardware.

Commands:
5.6. Issues with queue_if_no_path feature If a multipath device is configured with features "1 queue_if_no_path" , then any process that issues I/O will hang until one or more paths are restored. To avoid this, set the no_path_retry N parameter in the /etc/multipath.conf file (where N is the number of times the system should retry a path). Setting the no_path_retry parameter overrides the feature option features "1 queue_if_no_path" , even if this features option is set in the devices section and no_path_retry is set in the defaults section of the multipath configuration file. If you need to use the features "1 queue_if_no_path" option and you experience the issue noted here, use the dmsetup command to edit the policy at runtime for a particular LUN (that is, for which all the paths are unavailable). For example, if you want to change the policy on the multipath device mpathc from "queue_if_no_path" to "fail_if_no_path" , execute the following command. Note that you must specify the mpath n alias rather than the path.

Commands:
dmsetup message mpathc 0 "fail_if_no_path"
8.7. Receive Packet Steering (RPS) Receive Packet Steering (RPS) is similar to RSS in that it is used to direct packets to specific CPUs for processing. However, RPS is implemented at the software level, and helps to prevent the hardware queue of a single network interface card from becoming a bottleneck in network traffic. RPS has several advantages over hardware-based RSS: RPS can be used with any network interface card. It is easy to add software filters to RPS to deal with new protocols. RPS does not increase the hardware interrupt rate of the network device. However, it does introduce inter-processor interrupts. RPS is configured per network device and receive queue, in the /sys/class/net/ device /queues/ rx-queue /rps_cpus file, where device is the name of the network device (such as eth0 ) and rx-queue is the name of the appropriate receive queue (such as rx-0 ). The default value of the rps_cpus file is zero. This disables RPS, so the CPU that handles the network interrupt also processes the packet. To enable RPS, configure the appropriate rps_cpus file with the CPUs that should process packets from the specified network device and receive queue. The rps_cpus files use comma-delimited CPU bitmaps. Therefore, to allow a CPU to handle interrupts for the receive queue on an interface, set the value of their positions in the bitmap to 1. For example, to handle interrupts with CPUs 0, 1, 2, and 3, set the value of rps_cpus to 00001111 (1+2+4+8), or f (the hexadecimal value for 15). For network devices with single transmit queues, best performance can be achieved by configuring RPS to use CPUs in the same memory domain. On non-NUMA systems, this means that all available CPUs can be used. If the network interrupt rate is extremely high, excluding the CPU that handles network interrupts may also improve performance. For network devices with multiple queues, there is typically no benefit to configuring both RPS and RSS, as RSS is configured to map a CPU to each receive queue by default. However, RPS may still be beneficial if there are fewer hardware queues than CPUs, and RPS is configured to use CPUs in the same memory domain.

Commands:
4.187. nautilus-open-terminal 4.187.1. RHBA-2011:1205 - nautilus-open-terminal bug fix update An updated nautilus-open-terminal package that fixes various bugs is now available for Red Hat Enterprise Linux 6. The nautilus-open-terminal extension provides the right-click "Open Terminal" option for Nautilus. This updated nautilus-open-terminal package includes fixes for the following bugs: BZ# 630236 This update adds the untranslated string which was missing in the Japanese translation of the graphical user interface. BZ# 640496 Previously, the terminal failed to start if the user used a shell other than bash. The problem was caused by incorrect invocation parameters, which have been fixed and the terminal now launches properly. BZ# 716398 Previously, nothing happened if there was no terminal application installed and the user right-clicked on the desktop and selected "Open Terminal". With this update, the gnome-terminal package has been set as a hard dependency to guarantee at least one terminal application is available. All users of nautilus-open-terminal are advised to upgrade to this updated package, which resolves these bugs.

Commands:
5.114. iptraf 5.114.1. RHBA-2012:0762 - iptraf bug fix update Updated iptraf packages that fix one bug are now available for Red Hat Enterprise Linux 6. IPTraf is a console-based network monitoring utility. IPTraf gathers data such as TCP connection packet and byte counts, interface statistics and activity indicators, TCP/UDP traffic breakdowns, and LAN station packet and byte counts. Bug Fix BZ# 682350 Prior to this update, interface names were checked by IPTraf against a whitelist of names to determine whether an interface was supported. Network devices can have arbitrary names and due to the changes for "Consistent Network Device Naming", the interface names will change to location-based names. Consequently, IPTraf could reject certain interface names. This update removes the interface name check and as a result IPTraf always accepts device names. All users of iptraf are advised to upgrade to these updated packages, which fix this bug.

Commands:
7.4. Configuring Transparent Huge Pages Transparent Huge Pages (THP) is an alternative solution to HugeTLB. With THP, the kernel automatically assigns huge pages to processes, so huge pages do not need to be reserved manually. The THP feature has two modes of operation: system-wide and per-process. When THP is enabled system-wide, the kernel tries to assign huge pages to any process when it is possible to allocate huge pages and the process is using a large contiguous virtual memory area. If THP is enabled per-process, the kernel only assigns huge pages to individual processes' memory areas specified with the madvise() system call. Note that the THP feature only supports 2-MB pages. Transparent huge pages are enabled by default. To check the current status, run: To enable transparent huge pages, run: To prevent applications from allocating more memory resources than necessary, you can disable huge pages system-wide and only enable them inside MADV_HUGEPAGE madvise regions by running: To disable transparent huge pages, run: Sometimes, providing low latency to short-lived allocations has higher priority than immediately achieving the best performance with long-lived allocations. In such cases, direct compaction can be disabled while leaving THP enabled. Direct compaction is a synchronous memory compaction during the huge page allocation. Disabling direct compaction provides no guarantee of saving memory, but can decrease the risk of higher latencies during frequent page faults. Note that if the workload benefits significantly from THP, the performance decreases. To disable direct compaction, run: For comprehensive information on transparent huge pages, see the /usr/share/doc/kernel-doc- kernel_version /Documentation/vm/transhuge.txt file, which is available after installing the kernel-doc package.

Commands:
cat /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
Chapter 5. Installing a three-node cluster on AWS In OpenShift Container Platform version 4.16, you can install a three-node cluster on Amazon Web Services (AWS). A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. Note Deploying a three-node cluster using an AWS Marketplace image is not supported. 5.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 5.2. steps Installing a cluster on AWS with customizations Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 37. Managing the mptcpd service This section describes the basic management of the mptcpd service. The mptcpd package provides the mptcpize tool, which switches on the mptcp protocol in the TCP environment. 37.1. Configuring mptcpd The mptcpd service is a component of the mptcp protocol which provides an instrument to configure mptcp endpoints. The mptcpd service creates a subflow endpoint for each address by default. The endpoint list is updated dynamically according to IP addresses modification on the running host. The mptcpd service creates the list of endpoints automatically. It enables multiple paths as an alternative to using the ip utility. Prerequisites The mptcpd package installed Procedure Enable mptcp.enabled option in the kernel with the following command: Start the mptcpd service: Verify endpoint creation: To stop the mptcpd service, use the following command: To configure mptcpd service manually, modify the /etc/mptcpd/mptcpd.conf configuration file. Note, that the endpoint, which mptcpd service creates, lasts till the host shutdown. Additional resources mptcpd(8) man page on your system. 37.2. Managing applications with mptcpize tool Using the mptcpize tool manage applications and services. The instruction below shows how to use the mptcpize tool to manage applications in the TCP environment. Assuming, you need to run the iperf3 utility with the enabled MPTCP socket. You can achieve this goal by following the procedure below. Prerequisites The mptcpd package is installed The iperf3 package is installed Procedure Start iperf3 utility with MPTCP sockets enabled: 37.3. Enabling MPTCP sockets for a service by using the mptcpize utility The following set of commands instruct you how to manage services using the mptcpize tool. You can enable or disable the mptcp socket for a service. Assuming, you need to manage mptcp socket for the nginx service. You can achieve this goal by following the procedure below. Prerequisites The mptcpd package is installed The nginx package is installed Procedure Enable MPTCP sockets for a service: Disable the MPTCP sockets for a service: Restart the service to make the changes to take effect:

Commands:
echo "net.mptcp.enabled=1" > /etc/sysctl.d/90-enable-MPTCP.conf sysctl -p /etc/sysctl.d/90-enable-MPTCP.conf
systemctl start mptcp.service
ip mptcp endpoint
systemctl stop mptcp.service
mptcpize run iperf3 -s &
mptcpize enable nginx
mptcpize disable nginx
systemctl restart nginx
2.5. Technical Metadata Technical metadata represents information that describes how to access the data in its original native data storage. Technical metadata includes things such as datatype, the name of the data in the enterprise information system, and other information that describes the way the native enterprise information system identifies the meta object. Using our example of an address book database, the following represent the technical metadata we know about the ZIP code column: Named ZIPCode Nine characters long A string Located in the StreetAddress table Uses SQL Query Language These bits of information describe the data and information required to access and process the data in the enterprise information system.

Commands: