mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Example of Setting Up Apache HTTP Server This appendix provides an example of setting up a highly available Apache HTTP Server on a Red Hat Cluster. The example describes how to set up a service to fail over an Apache HTTP Server. Variables in the example apply to this example only; they are provided to assist setting up a service that suits your requirements. Note This example uses the Cluster Configuration Tool ( system-config-cluster ). You can use comparable Conga functions to make an Apache HTTP Server highly available on a Red Hat Cluster. A.1. Apache HTTP Server Setup Overview First, configure Apache HTTP Server on all nodes in the cluster. If using a failover domain , assign the service to all cluster nodes configured to run the Apache HTTP Server. Refer to Section 5.6, "Configuring a Failover Domain" for instructions. The cluster software ensures that only one cluster system runs the Apache HTTP Server at one time. The example configuration consists of installing the httpd RPM package on all cluster nodes (or on nodes in the failover domain, if used) and configuring a shared GFS shared resource for the Web content. When installing the Apache HTTP Server on the cluster systems, run the following command to ensure that the cluster nodes do not automatically start the service when the system boots: Rather than having the system init scripts spawn the httpd daemon, the cluster infrastructure initializes the service on the active cluster node. This ensures that the corresponding IP address and file system mounts are active on only one cluster node at a time. When adding an httpd service, a floating IP address must be assigned to the service so that the IP address will transfer from one cluster node to another in the event of failover or service relocation. The cluster infrastructure binds this IP address to the network interface on the cluster system that is currently running the Apache HTTP Server. This IP address ensures that the cluster node running httpd is transparent to the clients accessing the service. The file systems that contain the Web content cannot be automatically mounted on the shared storage resource when the cluster nodes boot. Instead, the cluster software must mount and unmount the file system as the httpd service is started and stopped. This prevents the cluster systems from accessing the same data simultaneously, which may result in data corruption. Therefore, do not include the file systems in the /etc/fstab file.

Commands:
chkconfig --del httpd
Chapter 283. Ribbon Component Available as of Camel version 2.18 The ribbon component provides use of Netflix Ribbon for client side load balancing. Maven users will need to add the following dependency to their pom.xml for this component: <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-ribbon</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency> This component helps applying load balancing feature at the client side when using ServiceCall EIP . 283.1. Configuration Programmatic RibbonConfiguration configuration = new RibbonConfiguration(); configuration.addProperties("ServerListRefreshInterval", "250"); RibbonLoadBalancer loadBalancer = new RibbonLoadBalancer(configuration); from("direct:start") .serviceCall() .name("myService") .loadBalancer(loadBalancer) .consulServiceDiscovery() .end() .to("mock:result"); Spring Boot application.properties camel.cloud.ribbon.properties[ServerListRefreshInterval] = 250 routes from("direct:start") .serviceCall() .name("myService") .ribbonLoadBalancer() .consulServiceDiscovery() .end() .to("mock:result"); XML <route> <from uri="direct:start"/> <serviceCall name="myService"> <!-- enable ribbon load balancer --> <ribbonLoadBalancer> <properties key="ServerListRefreshInterval" value="250"/> </ribbonLoadBalancer> </serviceCall> </route> 283.2. See Also ServiceCall EIP

Commands:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-ribbon</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
RibbonConfiguration configuration = new RibbonConfiguration(); configuration.addProperties("ServerListRefreshInterval", "250"); RibbonLoadBalancer loadBalancer = new RibbonLoadBalancer(configuration); from("direct:start") .serviceCall() .name("myService") .loadBalancer(loadBalancer) .consulServiceDiscovery() .end() .to("mock:result");
camel.cloud.ribbon.properties[ServerListRefreshInterval] = 250
from("direct:start") .serviceCall() .name("myService") .ribbonLoadBalancer() .consulServiceDiscovery() .end() .to("mock:result");
<route> <from uri="direct:start"/> <serviceCall name="myService"> <!-- enable ribbon load balancer --> <ribbonLoadBalancer> <properties key="ServerListRefreshInterval" value="250"/> </ribbonLoadBalancer> </serviceCall> </route>
4.348. xdg-utils 4.348.1. RHBA-2011:1229 - xdg-utils bug fix update An updated xdg-utils package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The xdg-utils package is a set of simple scripts that provide basic desktop integration functions for any Free Desktop. Bug Fixes BZ# 659782 Previously, a trailing comma was passed in the "thunderbird" command. As a result, Thunderbird was unable to open a compose window. With this update, the trailing comma has been stripped so that Thunderbird now works properly. BZ# 659786 Previously, there was a typo found in the xdg-utils source code. As a consequence, Thunderbird, after passing in an email address, created a compose window without the "To:" address. With this update, the typo has been fixed so that the "To:" address is now passed in correctly. All xdg-utils users are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 48. limits This chapter describes the commands under the limits command. 48.1. limits show Show compute and block storage limits Usage: Table 48.1. Command arguments Value Summary -h, --help Show this help message and exit --absolute Show absolute limits --rate Show rate limits --reserved Include reservations count [only valid with --absolute] --project <project> Show limits for a specific project (name or id) [only valid with --absolute] --domain <domain> Domain the project belongs to (name or id) [only valid with --absolute] Table 48.2. Output formatter options Value Summary -f {csv,json,table,value,yaml}, --format {csv,json,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns --sort-column SORT_COLUMN Specify the column(s) to sort the data (columns specified first have a priority, non-existing columns are ignored), can be repeated --sort-ascending Sort the column(s) in ascending order --sort-descending Sort the column(s) in descending order Table 48.3. CSV formatter options Value Summary --quote {all,minimal,none,nonnumeric} When to include quotes, defaults to nonnumeric Table 48.4. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 48.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack limits show [-h] [-f {csv,json,table,value,yaml}] [-c COLUMN] [--quote {all,minimal,none,nonnumeric}] [--noindent] [--max-width <integer>] [--fit-width] [--print-empty] [--sort-column SORT_COLUMN] [--sort-ascending | --sort-descending] (--absolute | --rate) [--reserved] [--project <project>] [--domain <domain>]
Chapter 6. Changes in Go Toolset Go Toolset has been updated from version 1.21 to 1.22 on RHEL 8 and RHEL 9. Notable changes include: Variables in for loops are now created per iteration, preventing accidental sharing bugs. Additionally, for loops can now range over integers. Commands in workspaces can now use a vendor directory for the dependencies of the workspace. The go get command no longer supports the legacy GOPATH mode. This change does not affect the go build and go test commands. The vet tool has been updated to match the new behavior of the for loops. CPU performance has been improved by keeping type-based garbage collection metadata nearer to each heap object. Go now provides improved inlining optimizations and better profile-guided optimization support for higher performance. A new math/rand/v2 package is available. Go now provides enhanced HTTP routing patterns with support for methods and wildcards. For detailed information regarding the updates, see the upstream Go 1.22 Release Notes .

Commands:
Chapter 1. Preparing to install on IBM Cloud VPC The installation workflows documented in this section are for IBM Cloud VPC infrastructure environments. IBM Cloud Classic is not supported at this time. For more information about the difference between Classic and VPC infrastructures, see the IBM documentation . 1.1. Prerequisites You reviewed details about the OpenShift Container Platform installation and update processes. You read the documentation on selecting a cluster installation method and preparing it for users . 1.2. Requirements for installing OpenShift Container Platform on IBM Cloud VPC Before installing OpenShift Container Platform on IBM Cloud VPC, you must create a service account and configure an IBM Cloud account. See Configuring an IBM Cloud account for details about creating an account, enabling API services, configuring DNS, IBM Cloud account limits, and supported IBM Cloud VPC regions. You must manually manage your cloud credentials when installing a cluster to IBM Cloud VPC. Do this by configuring the Cloud Credential Operator (CCO) for manual mode before you install the cluster. For more information, see Configuring IAM for IBM Cloud VPC . 1.3. Choosing a method to install OpenShift Container Platform on IBM Cloud VPC You can install OpenShift Container Platform on IBM Cloud VPC using installer-provisioned infrastructure. This process involves using an installation program to provision the underlying infrastructure for your cluster. Installing OpenShift Container Platform on IBM Cloud VPC using user-provisioned infrastructure is not supported at this time. See Installation process for more information about installer-provisioned installation processes. 1.3.1. Installing a cluster on installer-provisioned infrastructure You can install a cluster on IBM Cloud VPC infrastructure that is provisioned by the OpenShift Container Platform installation program by using one of the following methods: Installing a customized cluster on IBM Cloud VPC : You can install a customized cluster on IBM Cloud VPC infrastructure that the installation program provisions. The installation program allows for some customization to be applied at the installation stage. Many other customization options are available post-installation . Installing a cluster on IBM Cloud VPC with network customizations : You can customize your OpenShift Container Platform network configuration during installation, so that your cluster can coexist with your existing IP address allocations and adhere to your network requirements. Installing a cluster on IBM Cloud VPC into an existing VPC : You can install OpenShift Container Platform on an existing IBM Virtual Private Cloud (VPC). You can use this installation method if you have constraints set by the guidelines of your company, such as limits when creating new accounts or infrastructure. Installing a private cluster on an existing VPC : You can install a private cluster on an existing Virtual Private Cloud (VPC). You can use this method to deploy OpenShift Container Platform on an internal network that is not visible to the internet. 1.4. steps Configuring an IBM Cloud account

Commands:
2.8. Other Tools For Auditing Red Hat Enterprise Linux7 offers a few more tools with which to perform system auditing and analysis. Most of them can be used as supplementary sources of information in case you want to verify what you have discovered already or in case you need more in-depth information on certain parts. Many of these tools are used for performance tuning as well. They include: vmstat vmstat gives you detailed information about processes, memory, paging, block I/O, traps, and CPU activity. Use it to take a closer look at what the system overall does and where it is busy. iostat iostat is similar to vmstat , but only for I/O on block devices. It also provides more verbose output and statistics. blktrace blktrace is a very detailed block I/O trace program. It breaks down information to single blocks associated with applications. It is very useful in combination with diskdevstat .

Commands:
32.6. Additional Resources Installed Documentation kdump.conf (5) - a manual page for the /etc/kdump.conf configuration file containing the full documentation of available options. makedumpfile (8) - a manual page for the makedumpfile core collector. kexec (8) - a manual page for kexec . crash (8) - a manual page for the crash utility. /usr/share/doc/kexec-tools- version /kexec-kdump-howto.txt - an overview of the kdump and kexec installation and usage. /usr/share/doc/kexec-tools- version /fadump-howto.txt - more details about the fadump mechanism, including PowerPC-specific methods of resetting hardware. Replace version with kexec-tools version installed on your system. Useful Websites https://access.redhat.com/kb/docs/DOC-6039 The Red Hat Knowledgebase article about the kexec and kdump configuration. https://access.redhat.com/kb/docs/DOC-45183 The Red Hat Knowledgebase article about supported kdump targets. http://people.redhat.com/anderson/ The crash utility homepage.

Commands:
Chapter 5. DM Multipath Administration and Troubleshooting This chapter provides information on administering DM Multipath on a running system. 5.1. Automatic Configuration File Generation with Multipath Helper You can generate a basic configuration for multipath devices on Red Hat Enterprise Linux with the Multipath Helper application. The application gives you options to create multipath configurations with custom aliases, device blacklists, and settings for the characteristics of individual multipath devices. Upon completion, the application generates an installation script that includes the configuration parameters you selected and it provides a multipath.conf configuration file for review. The Multipath Helper application can be found at https://access.redhat.com/labsinfo/multipathhelper .

Commands:
Chapter 61. JmxTransQueryTemplate schema reference Used in: JmxTransSpec Property Property type Description targetMBean string If using wildcards instead of a specific MBean then the data is gathered from multiple MBeans. Otherwise if specifying an MBean then data is gathered from that specified MBean. attributes string array Determine which attributes of the targeted MBean should be included. outputs string array List of the names of output definitions specified in the spec.kafka.jmxTrans.outputDefinitions that have defined where JMX metrics are pushed to, and in which data format.

Commands:
5.2. Using Referential Integrity with Replication There are certain limitations when using the Referential Integrity Postoperation plug-in in a replication environment: Never enable it on a dedicated consumer server (a server that contains only read-only replicas). Never enable it on a server that contains a combination of read-write and read-only replicas. Enable it on a supplier server that contains only read-write replicas. Enable the plug-in for each supplier server in multi-supplier replication topology. The plug-in configuration must be the same on all supplier servers. Note Because the supplier server sends any changes made by the Referential Integrity Postoperation plug-in to consumer servers, it is unnecessary to run the Referential Integrity Postoperation plug-in on consumer and hub servers.

Commands:
25.3.2.2. Persistently Adding an LCS Device cio_ignore is handled transparently for persistent device configurations and you do not need to free devices from the ignore list manually. To add an LCS device persistently, follow these steps: Create a configuration script as file in /etc/sysconfig/network-scripts/ with a name like ifcfg-eth n where n is an integer starting with 0 . The file should look similar to the following: Modify the value of PORTNAME to reflect the LCS port number ( portno ) you would like to use. You can add any valid lcs sysfs attribute and its value to the optional OPTIONS parameter. Refer to Section 25.3.1.3, "Persistently Adding a qeth Device" for the syntax. Set the DEVICE parameter as follows: Issue an ifup command to activate the device: Changes to an ifcfg file only become effective after rebooting the system. You can trigger the activation of a ifcfg file for network channels by executing the following commands: Use the cio_ignore command to remove the LCS device adapter from the list of ignored devices and make it visible to Linux: Replace read_device_bus_id and write_device_bus_id with the device bus IDs of the LCS device. For example: To trigger the uevent that activates the change, issue: For example:

Commands:
/etc/sysconfig/network-scripts/ifcfg-eth0 IBM LCS DEVICE=eth0 BOOTPROTO=static IPADDR=10.12.20.136 NETMASK=255.255.255.0 ONBOOT=yes NETTYPE=lcs SUBCHANNELS=0.0.09a0,0.0.09a1 PORTNAME=0 OPTIONS='' TYPE=Ethernet
DEVICE=eth n
ifup eth n
cio_ignore -r read_device_bus_id , write_device_bus_id
cio_ignore -r 0.0.09a0,0.0.09a1
echo add > /sys/bus/ccw/devices/ read-channel /uevent
echo add > /sys/bus/ccw/devices/0.0.09a0/uevent
10.4. Setting Cache Cull Limits The cachefilesd daemon works by caching remote data from shared file systems to free space on the disk. This could potentially consume all available free space, which could be bad if the disk also housed the root partition. To control this, cachefilesd tries to maintain a certain amount of free space by discarding old objects (i.e. accessed less recently) from the cache. This behavior is known as cache culling . Cache culling is done on the basis of the percentage of blocks and the percentage of files available in the underlying file system. There are six limits controlled by settings in /etc/cachefilesd.conf : brun N % (percentage of blocks) , frun N % (percentage of files) If the amount of free space and the number of available files in the cache rises above both these limits, then culling is turned off. bcull N % (percentage of blocks), fcull N % (percentage of files) If the amount of available space or the number of files in the cache falls below either of these limits, then culling is started. bstop N % (percentage of blocks), fstop N % (percentage of files) If the amount of available space or the number of available files in the cache falls below either of these limits, then no further allocation of disk space or files is permitted until culling has raised things above these limits again. The default value of N for each setting is as follows: brun / frun - 10% bcull / fcull - 7% bstop / fstop - 3% When configuring these settings, the following must hold true: 0 <= bstop < bcull < brun < 100 0 <= fstop < fcull < frun < 100 These are the percentages of available space and available files and do not appear as 100 minus the percentage displayed by the df program. Important Culling depends on both b xxx and f xxx pairs simultaneously; they can not be treated separately.

Commands:
Chapter 7. Ansible Automation Platform documentation Red Hat Ansible Automation Platform 2.4 documentation includes significant feature updates as well as documentation enhancements and offers an improved user experience. New features and enhancements With the removal of the on-premise component automation services catalog from Ansible Automation Platform 2.4 onwards, all automation services catalog documentation is removed from the Ansible Automation Platform 2.4 documentation. The following documents are created to help you install and use Event-Driven Ansible, the newest capability of Ansible Automation Platform: Getting Started with Event-Driven Ansible Event Driven Ansible User Guide In addition, sections of the Ansible Automation Platform Planning Guide and the Ansible Automation Platform Installation Guide are updated to include instructions for planning and installing Event-Driven Ansible. The automation hub documentation has had significant reorganization to combine the content spread across 9 separate documents into the following documents: Getting started with automation hub Use this guide to perform the initial steps required to use Red Hat automation hub as the default source for Ansible collections content. Managing content in automation hub Use this guide to understand how to create and manage collections, content and repositories in automation hub. Red Hat Ansible Automation Platform Installation Guide Use this guide to learn how to install Ansible Automation Platform based on supported installation scenarios. The Managing Red Hat Certified and Ansible Galaxy collections in automation hub guide has been moved to the Red Hat Certified, validated, and Ansible Galaxy content in automation hub topic in the Managing content in automation hub guide. The Ansible Automation Platform 2.4 Release Notes are restructured to improve the experience for our customers and the Ansible Community. Users can now view the latest updates based on the Ansible Automation Platform versions, instead of their release timeline. The topic Repository management with automation hub is created to help you create and manage custom repositories in automation hub. This topic is found in the Managing content in automation hub guide.

Commands:
Chapter 1. Reporting in Red Hat Ansible Inside To comply with your Red Hat Ansible Inside subscription requirements, you must send metrics files about your automation usage to Red Hat. This guide describes the data that is collected, how to implement its collection, and how the data is returned to Red Hat. 1.1. About reporting metrics Ansible Inside saves high-level usage data about your automation jobs. Red Hat uses this data to identify where to focus effort in product improvements and new features. After an automation job is completed, metrics are gathered to save the following information about the job: The type, duration, and time of the automation job. The names of the collections and roles used in the job, and the number of times they are used. The number of nodes that were installed, updated, failed, and skipped. The events that occurred during the job. Note Red Hat does not gather Personal Identifiable Information (PII), such as IP addresses, location, user details, or operating system specification. The following architecture diagram illustrates how the data is saved to the persistent data storage outside the Python application so that it can be sent to Red Hat. 1.2. About the metrics files The metrics data is bundled into a tarball file. A separate file is generated for each job. You can view the contents of the files: they are not encrypted. Each tarball file contains the following unencrypted CSV files: jobs.csv records the duration and status of the automation job, the number of tasks executed, and the number of hosts that were affected by the job. modules.csv records the module name, the task count and the duration. collections.csv : records the collection name, the task count and the duration. roles.csv records the role name, the task count and the duration. playbook_on_stats.csv records the event ID and data.

Commands: