mtpti5iD/redhat-docs_dataset huggingface dataset:
31.3. Dual Head Display Settings If multiple video cards are installed on the system, dual head monitor support is available and is configured via the Dual head tab, as shown in Figure 31.3, "Dual Head Display Settings" . Figure 31.3. Dual Head Display Settings To enable use of Dual head, check the Use dual head checkbox. To configure the second monitor type, click the corresponding Configure button. You can also configure the other Dual head settings by using the corresponding drop-down list. For the Desktop layout option, selecting Spanning Desktops allows both monitors to use an enlarged usable workspace. Selecting Individual Desktops shares the mouse and keyboard among the displays, but restricts windows to a single display.

Commands:
4.6.2. REAL SERVER Subsection Clicking on the REAL SERVER subsection link at the top of the panel displays the EDIT REAL SERVER subsection. It displays the status of the physical server hosts for a particular virtual service. Figure 4.7. The REAL SERVER Subsection Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Figure 4.8, "The REAL SERVER Configuration Panel" . Figure 4.8. The REAL SERVER Configuration Panel This panel consists of three entry fields: Name A descriptive name for the real server. Note This name is not the hostname for the machine, so make it descriptive and easily identifiable. Address The real server's IP address. Since the listening port is already specified for the associated virtual server, do not add a port number. Weight An integer value indicating this host's capacity relative to that of other hosts in the pool. The value can be arbitrary, but treat it as a ratio in relation to other real servers in the pool. For more on server weight, see Section 1.3.2, "Server Weight and Scheduling" . Warning Remember to click the ACCEPT button after making any changes in this panel. To make sure you do not lose any changes when selecting a new panel.

Commands:
Chapter 8. Ceph debugging and logging configuration As a storage administrator, you can increase the amount of debugging and logging information to help diagnose problems with the Red Hat Ceph Storage. 8.1. Prerequisites Installation of the Red Hat Ceph Storage software. 8.2. Ceph debugging and logging Debug settings are NOT required in the Ceph configuration file, but can be added to optimize logging. Changes to the Ceph logging configuration usually occur at runtime when a problem occurs, but may also be modified in the Ceph configuration file. For example, if there are issues when starting the cluster, consider increasing log settings in the Ceph configuration file. When the problem is resolved, remove the settings or restore them to optimal settings for runtime operations. By default, view Ceph log files under /var/log/ceph . Tip When debug output slows down the cluster, the latency can hide race conditions. Logging is resource intensive. If there is a problem in a specific area of the cluster, enable logging for that area of the cluster. For example, if OSDs are running fine but Ceph Object Gateways are not, start by enabling debug logging for the specific gateway instances encountering problems. Increase or decrease logging for each subsystem as needed. Important Verbose logging can generate over 1GB of data per hour. If the OS disk reaches its capacity, the node will stop working. If Ceph logging is enabled or the rate of logging increased, ensure that the OS disk has sufficient capacity. When the cluster is running well, remove unnecessary debugging settings to ensure the cluster runs optimally. Logging debug output messages is relatively slow, and a waste of resources when operating your cluster. 8.3. Additional Resources See all the Red Hat Ceph Storage Ceph debugging and logging configuration options in Appendix J for specific option descriptions and usage.

Commands:
Chapter 9. Configure maximum transmission unit (MTU) settings 9.1. MTU overview OpenStack Networking can calculate the largest possible maximum transmission unit (MTU) size that you can apply safely to instances. The MTU value specifies the maximum amount of data that a single network packet can transfer; this number is variable depending on the most appropriate size for the application. For example, NFS shares might require a different MTU size to that of a VoIP application. Note You can use the neutron net-show command to view the largest possible MTU values that OpenStack Networking calculates. net-mtu is a neutron API extension that is not present in some implementations. The MTU value that you require can be advertised to DHCPv4 clients for automatic configuration, if supported by the instance, as well as to IPv6 clients through Router Advertisement (RA) packets. To send Router Advertisements, the network must be attached to a router. You must configure MTU settings consistently from end-to-end. This means that the MTU setting must be the same at every point the packet passes through, including the VM, the virtual network infrastructure, the physical network, and the destination server. For example, the circles in the following diagram indicate the various points where an MTU value must be adjusted for traffic between an instance and a physical server. You must change the MTU value for very interface that handles network traffic to accommodate packets of a particular MTU size. This is necessary if traffic travels from the instance 192.168.200.15 through to the physical server 10.20.15.25 : Inconsistent MTU values can result in several network issues, the most common being random packet loss that results in connection drops and slow network performance. Such issues are problematic to troubleshoot because you must identify and examine every possible network point to ensure it has the correct MTU value. 9.2. Configuring MTU Settings in Director This example demonstrates how to set the MTU using the NIC config templates. You must set the MTU on the bridge, bond (if applicable), interface(s), and VLAN(s): 9.3. Reviewing the resulting MTU calculation You can view the calculated MTU value, which is the largest possible MTU value that instances can use. Use this calculated MTU value to configure all interfaces involved in the path of network traffic.

Commands:
- type: ovs_bridge name: br-isolated use_dhcp: false mtu: 9000 # <--- Set MTU members: - type: ovs_bond name: bond1 mtu: 9000 # <--- Set MTU ovs_options: {get_param: BondInterfaceOvsOptions} members: - type: interface name: ens15f0 mtu: 9000 # <--- Set MTU primary: true - type: interface name: enp131s0f0 mtu: 9000 # <--- Set MTU - type: vlan device: bond1 vlan_id: {get_param: InternalApiNetworkVlanID} mtu: 9000 # <--- Set MTU addresses: - ip_netmask: {get_param: InternalApiIpSubnet} - type: vlan device: bond1 mtu: 9000 # <--- Set MTU vlan_id: {get_param: TenantNetworkVlanID} addresses: - ip_netmask: {get_param: TenantIpSubnet}
openstack network show <network>
Chapter 3. Granting administration permissions to manage a CUPS server in the web interface By default, members of the sys , root , and wheel groups can perform administration tasks in the web interface. However, certain other services use these groups as well. For example, members of the wheel groups can, by default, execute commands with root permissions by using sudo . To avoid that CUPS administrators gain unexpected permissions in other services, use a dedicated group for CUPS administrators. Prerequisites CUPS is configured . The IP address of the client you want to use has permissions to access the administration area in the web interface. Procedure Create a group for CUPS administrators: Add the users who should manage the service in the web interface to the cups-admins group: Update the value of the SystemGroup parameter in the /etc/cups/cups-files.conf file, and append the cups-admin group: If only the cups-admin group should have administrative access, remove the other group names from the parameter. Restart CUPS: Verification Use a browser, and access https:// <hostname_or_ip_address> :631/admin/ . Note You can access the administration area in the web UI only if you use the HTTPS protocol. Start performing an administrative task. For example, click Add printer . The web interface prompts for a username and password. To proceed, authenticate by using credentials of a user who is a member of the cups-admins group. If authentication succeeds, this user can perform administrative tasks.

Commands:
groupadd cups-admins
usermod -a -G cups-admins <username>
SystemGroup sys root wheel cups-admins
systemctl restart cups
Appendix B. Revision History Revision History Revision 2.2-9 Mon Aug 05 2019 Marie Dolezelova Document version for 7.7 GA publication. Revision 2.2-6 Mon Jul 24 2017 Marie Dolezelova Document version for 7.4 GA publication. Revision 2.2-5 Tue Mar 21 2017 Milan Navratil Asynchronous update: the Tuned chapter rewrite Revision 2.0-2 Fri Oct 14 2016 Marie Dolezelova Version for 7.3 GA publication. Revision 2.0-1 Wed 11 Nov 2015 Jana Heves Version for 7.2 GA release. Revision 1-3 Fri 19 Jun 2015 Jacquelynn East Fixed incorrect package name in Core Infrastructure and Mechanics. Revision 1-2 Wed 18 Feb 2015 Jacquelynn East Version for 7.1 GA Revision 1-1 Thu Dec 4 2014 Jacquelynn East Version for 7.1 Beta Revision 1.0-9 Tue Jun 9 2014 Yoana Ruseva Version for 7.0 GA release Revision 0.9-1 Fri May 9 2014 Yoana Ruseva Rebuild for style changes. Revision 0.9-0 Wed May 7 2014 Yoana Ruseva Red Hat Enterprise Linux 7.0 release of the book for review purposes. Revision 0.1-1 Thu Jan 17 2013 Jack Reed Branched from the Red Hat Enterprise Linux 6 version of the document

Commands:
8.144. mod_wsgi 8.144.1. RHBA-2014:1612 - mod_wsgi bug fix update Updated mod_wsgi packages that fix one bug are now available for Red Hat Enterprise Linux 6. The mod_wsgi adapter is an Apache module that provides a WSGI-compliant interface for hosting Python-based web applications within Apache. Bug Fix BZ# 1008018 When stopping the httpd daemon with the mod_wsgi module, a short race condition occurred right after its start, during which httpd could terminate unexpectedly with errors. This bug has been fixed and httpd no longer crashes in the described conditions. Users of mod_wsgi are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 1. Red Hat High Availability Add-On Configuration and Management Reference Overview This document provides descriptions of the options and features that the Red Hat High Availability Add-On using Pacemaker supports. This manual documents the use of the pcs configuration interface for the Red Hat Enterprise Linux Release 6.6 and later. Note For information on best practices for deploying and upgrading Red Hat Enterprise Linux clusters using the High Availability Add-On and Red Hat Global File System 2 (GFS2) see the article "Red Hat Enterprise Linux Cluster, High Availability, and GFS Deployment Best Practices" on Red Hat Customer Portal at https://access.redhat.com/kb/docs/DOC-40821 . 1.1. Installing Pacemaker configuration tools You can use the following yum install command to install the Red Hat High Availability Add-On software packages along with all available: fence agents from the High Availability channel. The lvm2-cluster and gfs2-utils packages are part of ResilientStorage channel. You can install them, as needed, with the following command. Warning After you install the Red Hat High Availability Add-On packages, you should ensure that your software update preferences are set so that nothing is installed automatically. Installation on a running cluster can cause unexpected behaviors.

Commands:
yum install pcs pacemaker cman fence-agents
yum install lvm2-cluster gfs2-utils
14.4. Mapping an Image Using the qemu-img map command, your can dump the metadata of the specified image file ( imgname ) and its backing file chain. The dump shows the allocation state of every sector in the ( imgname ) with the topmost file that allocates it in the backing file chain. Optionally, specify the file's format type ( fmt ). There are two output formats, the human format and the json format: 14.4.1. The human Format The default format ( human ) only dumps non-zero, allocated parts of the file. The output identifies a file from where data can be read and the offset in the file. Each line includes four fields. The following shows an example of an output: The first line means that 0x20000 (131072) bytes starting at offset 0 in the image are available in tmp/overlay.qcow2 (opened in raw format) starting at offset 0x50000 (327680). Data that is compressed, encrypted, or otherwise not available in raw format causes an error if human format is specified. Note File names can include newline characters. Therefore, it is not safe to parse output in human format in scripts. 14.4.2. The json Format If the json option is specified, the output returns an array of dictionaries in JSON format. In addition to the information provided in the human option, the output includes the following information: data - A Boolean field that shows whether or not the sectors contain data zero - A Boolean field that shows whether or not the data is known to read as zero depth - The depth of the backing file of filename Note When the json option is specified, the offset field is optional. For more information about the qemu-img map command and additional options, see the relevant man page.

Commands:
qemu-img map [-f fmt ] [--output= fmt ] imgname
Offset Length Mapped to File 0 0x20000 0x50000 /tmp/overlay.qcow2 0x100000 0x10000 0x95380000 /tmp/backing.qcow2
Part V. Installing and configuring KIE Server on IBM WebSphere Application Server Red Hat Decision Manager is a subset of Red Hat Process Automation Manager. Starting with this release, the distribution files for Red Hat Decision Manager are replaced with Red Hat Process Automation Manager files. There are no Decision Manager artifacts. The Red Hat Decision Manager subscription, support entitlements, and fees remain the same. Red Hat Decision Manager subscribers will continue to receive full support for the decision management and optimization capabilities of Red Hat Decision Manager. The business process management (BPM) capabilities of Red Hat Process Automation Manager are exclusive to Red Hat Process Automation Manager subscribers. They are available for use by Red Hat Decision Manager subscribers but with development support services only. Red Hat Decision Manager subscribers can upgrade to a full Red Hat Process Automation Manager subscription at any time to receive full support for BPM features. As a system administrator, you can configure your IBM WebSphere Application Server for Red Hat KIE Server and install KIE Server on that IBM server instance. Note Support for Red Hat Decision Manager on IBM WebSphere Application Server is now in the maintenance phase. Red Hat will continue to support Red Hat Process Automation Manager on IBM WebSphere Application Server with the following limitations: Red Hat will not release new certifications or software functionality. Red Hat will release only qualified security patches that have a critical impact and mission-critical bug fix patches. In the future, Red Hat might direct customers to migrate to new platforms and product components that are compatible with the Red Hat hybrid cloud strategy. Prerequisites An IBM WebSphere Application Server instance version 9.0 or later is installed. For complete installation instructions, see the IBM WebSphere Application Server product page . You have access to the WebSphere Integrated Solutions Console, usually at http://<HOST>:9060/ibm/console .

Commands:
4.5. alsa-lib 4.5.1. RHBA-2011:1719 - alsa-lib bug fix update Updated alsa-lib packages that fix one bug are now available for Red Hat Enterprise Linux 6. The alsa-lib packages contain libraries for the Advanced Linux Sound Architecture (ALSA). Bug Fix BZ# 704772 Prior to this update, the alsa output plugin for the Audacious Audio Player did not work correctly. As a result, Audacious could under certain circumstances fail to generate any sound and display error messages. With this update, alsa-lib is modified so that Audacious can now generate sound as expected. All alsa-lib users are advised to upgrade to these updated packages, which fix this bug.

Commands:
10.5.8. IfModule <IfModule> and </IfModule> tags create a conditional container which are only activated if the specified module is loaded. Directives within the IfModule container are processed under one of two conditions. The directives are processed if the module contained within the starting <IfModule> tag is loaded. Or, if an exclamation point ! appears before the module name, the directives are processed only if the module specified in the <IfModule> tag is not loaded. For more information about Apache HTTP Server modules, refer to Section 10.7, "Adding Modules" .

Commands:
Chapter 9. Getting started with XFS This is an overview of how to create and maintain XFS file systems. 9.1. The XFS file system XFS is a highly scalable, high-performance, robust, and mature 64-bit journaling file system that supports very large files and file systems on a single host. It is the default file system in Red Hat Enterprise Linux 9. XFS was originally developed in the early 1990s by SGI and has a long history of running on extremely large servers and storage arrays. The features of XFS include: Reliability Metadata journaling, which ensures file system integrity after a system crash by keeping a record of file system operations that can be replayed when the system is restarted and the file system remounted Extensive run-time metadata consistency checking Scalable and fast repair utilities Quota journaling. This avoids the need for lengthy quota consistency checks after a crash. Scalability and performance Supported file system size up to 1024 TiB Ability to support a large number of concurrent operations B-tree indexing for scalability of free space management Sophisticated metadata read-ahead algorithms Optimizations for streaming video workloads Allocation schemes Extent-based allocation Stripe-aware allocation policies Delayed allocation Space pre-allocation Dynamically allocated inodes Other features Reflink-based file copies Tightly integrated backup and restore utilities Online defragmentation Online file system growing Comprehensive diagnostics capabilities Extended attributes ( xattr ). This allows the system to associate several additional name/value pairs per file. Project or directory quotas. This allows quota restrictions over a directory tree. Subsecond timestamps Performance characteristics XFS has a high performance on large systems with enterprise workloads. A large system is one with a relatively high number of CPUs, multiple HBAs, and connections to external disk arrays. XFS also performs well on smaller systems that have a multi-threaded, parallel I/O workload. XFS has a relatively low performance for single threaded, metadata-intensive workloads: for example, a workload that creates or deletes large numbers of small files in a single thread. 9.2. Comparison of tools used with ext4 and XFS This section compares which tools to use to accomplish common tasks on the ext4 and XFS file systems. Task ext4 XFS Create a file system mkfs.ext4 mkfs.xfs File system check e2fsck xfs_repair Resize a file system resize2fs xfs_growfs Save an image of a file system e2image xfs_metadump and xfs_mdrestore Label or tune a file system tune2fs xfs_admin Back up a file system tar and rsync xfsdump and xfsrestore Quota management quota xfs_quota File mapping filefrag xfs_bmap Note If you want a complete client-server solution for backups over network, you can use bacula backup utility that is available in RHEL 9. For more information about Bacula, see Bacula backup solution .

Commands:
1.4. Routing Methods Red Hat Enterprise Linux uses Network Address Translation or NAT routing for LVS, which allows the administrator tremendous flexibility when utilizing available hardware and integrating the LVS into an existing network. 1.4.1. NAT Routing Figure 1.3, "LVS Implemented with NAT Routing" , illustrates LVS utilizing NAT routing to move requests between the Internet and a private network. Figure 1.3. LVS Implemented with NAT Routing In the example, there are two NICs in the active LVS router. The NIC for the Internet has a real IP address on eth0 and has a floating IP address aliased to eth0:1. The NIC for the private network interface has a real IP address on eth1 and has a floating IP address aliased to eth1:1. In the event of failover, the virtual interface facing the Internet and the private facing virtual interface are taken-over by the backup LVS router simultaneously. All of the real servers located on the private network use the floating IP for the NAT router as their default route to communicate with the active LVS router so that their abilities to respond to requests from the Internet is not impaired. In this example, the LVS router's public LVS floating IP address and private NAT floating IP address are aliased to two physical NICs. While it is possible to associate each floating IP address to its own physical device on the LVS router nodes, having more than two NICs is not a requirement. Using this topology, the active LVS router receives the request and routes it to the appropriate server. The real server then processes the request and returns the packets to the LVS router which uses network address translation to replace the address of the real server in the packets with the LVS routers public VIP address. This process is called IP masquerading because the actual IP addresses of the real servers is hidden from the requesting clients. Using this NAT routing, the real servers may be any kind of machine running various operating systems. The main disadvantage is that the LVS router may become a bottleneck in large cluster deployments because it must process outgoing as well as incoming requests.

Commands:
4.5. Networking When configuring a network interface manually, including static IP addresses and search domains, it is possible that a search entry will not be propagated to /etc/resolv.conf . Consequently, short host names that do not include the domain name will fail to resolve. To workaround this issue, add a search entry manually to /etc/resolv.conf . To ensure that RFC3442-standard classless static routes provided by a DHCP server are processed correctly when using NetworkManager, the following lines should be placed into /etc/dhclient.conf or, if using per-interface DHCP options, /etc/dhclient-<ifname>.conf: These lines will ensure that RFC3442 classless static routes are requested from the DHCP server, and that they are properly processed by NetworkManager.

Commands:
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; option ms-classless-static-routes code 249 = array of unsigned integer 8; also request rfc3442-classless-static-routes; also request ms-classless-static-routes;