mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Private automation hub Ansible automation hub is the central repository place for the certified collections, and functions as the main source of trusted, tested and supported content. With private automation hub, automation developers can collaborate and publish their own automation content and deliver Ansible code more easily within their organization. It is also the central repository for Ansible validated content, which is not supported, but is trusted and tested by Red Hat and our partners. 3.1. Required shared filesystem A high availability automation hub requires you to have a shared file system, such as NFS, already installed in your environment. Before you run the Red Hat Ansible Automation Platform installer, verify that you installed the /var/lib/pulp directory across your cluster as part of the shared file system installation. The Red Hat Ansible Automation Platform installer returns an error if /var/lib/pulp is not detected in one of your nodes, causing your high availability automation hub setup to fail. 3.2. Setting up the shared filesystem You must mount the shared file system on each automation hub node: Procedure Create the /var/lib/pulp directory. # mkdir /var/lib/pulp Mount the shared filesystem (this reference environment uses an NFS share). # mount -t nfs4 <nfs_share_ip_address>:/ /var/lib/pulp Confirm that the shared filesystem is successfully mounted: USD df -h 3.3. Enabling firewall services Because of the requirement of using a shared filesystem as part of a highly available Ansible automation hub environment, the following firewall services must be enabled to ensure that the filesystem is successfully mounted. On each Ansible automation hub node, you must: Ensure the following firewalld services ( nfs , mountd , rpc-bind ) are enabled. # firewall-cmd --zone=public --add-service=nfs # firewall-cmd --zone=public --add-service=mountd # firewall-cmd --zone=public --add-service=rpc-bind Reload firewalld for changes to take effect. # firewall-cmd --reload Verify the firewalld services are enabled. # firewall-cmd --get-services

Commands:
mkdir /var/lib/pulp
mount -t nfs4 <nfs_share_ip_address>:/ /var/lib/pulp
df -h
firewall-cmd --zone=public --add-service=nfs firewall-cmd --zone=public --add-service=mountd firewall-cmd --zone=public --add-service=rpc-bind
firewall-cmd --reload
firewall-cmd --get-services
Appendix F. Revision History Revision History Revision 9-3 Wed Mar 15 2017 Mirek Jahoda Version for 6.9 GA publication. Revision 8-3 Mon May 30 2016 Maxim Svistunov The /proc/meminfo appendix section updated; made minor improvements. Revision 8-2 Wed May 25 2016 Maxim Svistunov Added Relax-and-Recover (ReaR) ; made minor improvements. Revision 8-1 Thu May 10 2016 Maxim Svistunov Red Hat Enterprise Linux 6.8 GA release of the Deployment Guide. Revision 7-1 Tue Jul 14 2015 Barbora Ancincova Red Hat Enterprise Linux 6.7 GA release of the Deployment Guide. Revision 7-0 Fri Apr 17 2015 Barbora Ancincova Red Hat Enterprise Linux 6.7 Beta release of the Deployment Guide. Revision 6-3 Thu Apr 2 2015 Barbora Ancincova Updated TigerVNC , Viewing and Managing Log Files , Registering the System and Managing Subscriptions , and The kdump Crash Recovery Service . Revision 6-2 Fri Oct 14 2014 Barbora Ancincova Red Hat Enterprise Linux 6.6 GA release of the Deployment Guide. Revision 6-1 Fri Aug 22 2014 Jaromir Hradilek Updated NetworkManager , Network Interfaces , Configuring Authentication , The kdump Crash Recovery Service , and The proc File System . Revision 6-0 Mon Aug 11 2014 Jaromir Hradilek Red Hat Enterprise Linux 6.6 Beta release of the Deployment Guide. Revision 5-1 Thu Nov 21 2013 Jaromir Hradilek Red Hat Enterprise Linux 6.5 GA release of the Deployment Guide. Revision 5-0 Thu Oct 3 2013 Jaromir Hradilek Red Hat Enterprise Linux 6.5 Beta release of the Deployment Guide. Revision 4-1 Thu Feb 21 2013 Jaromir Hradilek Red Hat Enterprise Linux 6.4 GA release of the Deployment Guide. Revision 4-0 Thu Dec 6 2012 Jaromir Hradilek Red Hat Enterprise Linux 6.4 Beta release of the Deployment Guide. Revision 3-1 Wed Jun 20 2012 Jaromir Hradilek Red Hat Enterprise Linux 6.3 GA release of the Deployment Guide. Revision 3-0 Tue Apr 24 2012 Jaromir Hradilek Red Hat Enterprise Linux 6.3 Beta release of the Deployment Guide. Revision 2-1 Tue Dec 6 2011 Jaromir Hradilek Red Hat Enterprise Linux 6.2 GA release of the Deployment Guide. Revision 2-0 Mon Oct 3 2011 Jaromir Hradilek Red Hat Enterprise Linux 6.2 Beta release of the Deployment Guide. Revision 1-1 Wed May 19 2011 Jaromir Hradilek Red Hat Enterprise Linux 6.1 GA release of the Deployment Guide. Revision 1-0 Tue Mar 22 2011 Jaromir Hradilek Red Hat Enterprise Linux 6.1 Beta release of the Deployment Guide. Revision 0-1 Tue Nov 9 2010 Douglas Silas Red Hat Enterprise Linux 6.0 GA release of the Deployment Guide. Revision 0-0 Mon Nov 16 2009 Douglas Silas Initialization of the Red Hat Enterprise Linux 6 Deployment Guide.

Commands:
Chapter 4. Advisories related to this release The following advisories are issued to document bug fixes and CVE fixes included in this release: RHSA-2023:1903 RHSA-2023:1904 RHSA-2023:1905 RHSA-2023:1906 RHSA-2023:1907 RHSA-2023:1908 RHSA-2023:1909 RHSA-2023:1910 RHSA-2023:1911 RHSA-2023:1912 Revised on 2024-05-10 09:06:09 UTC

Commands:
3.2. Ignoring Local Disks when Generating Multipath Devices Some machines have local SCSI cards for their internal disks. DM Multipath is not recommended for these devices. If you set the find_multipaths configuration parameter to yes , you should not have to blacklist these devices. For information on the find_multipaths configuration parameter, see Section 4.3, "Configuration File Defaults" . If you do not set the find_multipaths configuration parameter to yes , can use the following procedure to modify the multipath configuration file to ignore the local disks when configuring multipath. Determine which disks are the internal disks and mark them as the ones to blacklist. In this example, /dev/sda is the internal disk. Note that as originally configured in the default multipath configuration file, executing the multipath -v2 command shows the local disk, /dev/sda , in the multipath map. This examples specifies the -d option of the multipath command to indicate that this is a dry run that will not create the multipath devices. For further information on the multipath command output, see Section 5.7, "Multipath Command Output" . In order to prevent the device mapper from mapping /dev/sda in its multipath maps, edit the blacklist section of the /etc/multipath.conf file to include this device. Although you could blacklist the sda device using a devnode type, that would not be a safe procedure since /dev/sda is not guaranteed to be the same on reboot. To blacklist individual devices, you can blacklist using the WWID of that device. Note that in the output to the multipath -v2 command, the WWID of the /dev/sda device is SIBM-ESXSST336732LC____F3ET0EP0Q000072428BX1. To blacklist this device, include the following in the /etc/multipath.conf file. After you have updated the /etc/multipath.conf file, you must manually tell the multipathd daemon to reload the file. The following command reloads the updated /etc/multipath.conf file.

Commands:
multipath -v2 -d : SIBM-ESXSST336732LC____F3ET0EP0Q000072428BX1 undef WINSYS,SF2372 size=33 GB features="0" hwhandler="0" wp=undef `-+- policy='round-robin 0' prio=1 status=undef |- 0:0:0:0 sda 8:0 [--------- : 3600a0b80001327d80000006d43621677 undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef |- 2:0:0:0 sdb 8:16 undef ready running `- 3:0:0:0 sdf 8:80 undef ready running : 3600a0b80001327510000009a436215ec undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef |- 2:0:0:1 sdc 8:32 undef ready running `- 3:0:0:1 sdg 8:96 undef ready running : 3600a0b80001327d800000070436216b3 undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef |- 2:0:0:2 sdd 8:48 undef ready running `- 3:0:0:2 sdg 8:112 undef ready running : 3600a0b80001327510000009b4362163e undef WINSYS,SF2372 size=12G features='0' hwhandler='0' wp=undef `-+- policy='round-robin 0' prio=1 status=undef |- 2:0:0:3 sdd 8:64 undef ready running `- 3:0:0:3 sdg 8:128 undef ready running
blacklist { wwid SIBM-ESXSST336732LC____F3ET0EP0Q000072428BX1 }
systemctl reload multipathd.service
4.5. REDUNDANCY The REDUNDANCY panel allows you to configure of the backup LVS router node and set various heartbeat monitoring options. Note The first time you visit this screen, it displays an "inactive" Backup status and an ENABLE button. To configure the backup LVS router, click on the ENABLE button so that the screen matches Figure 4.4, "The REDUNDANCY Panel" . Figure 4.4. The REDUNDANCY Panel Redundant server public IP Enter the public real IP address for the backup LVS router node. Redundant server private IP Enter the backup node's private real IP address in this text field. If you do not see the field called Redundant server private IP , go back to the GLOBAL SETTINGS panel and enter a Primary server private IP address and click ACCEPT . The rest of the panel is devoted to configuring the heartbeat channel, which is used by the backup node to monitor the primary node for failure. Heartbeat Interval (seconds) This field sets the number of seconds between heartbeats - the interval that the backup node will check the functional status of the primary LVS node. Assume dead after (seconds) If the primary LVS node does not respond after this number of seconds, then the backup LVS router node will initiate failover. Heartbeat runs on port This field sets the port at which the heartbeat communicates with the primary LVS node. The default is set to 539 if this field is left blank. 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 5. Network considerations for NFV The undercloud host requires at least the following networks: Provisioning network - Provides DHCP and PXE-boot functions to help discover bare-metal systems for use in the overcloud. External network - A separate network for remote connectivity to all nodes. The interface connecting to this network requires a routable IP address, either defined statically, or generated dynamically from an external DHCP service. The minimal overcloud network configuration includes the following NIC configurations: Single NIC configuration - One NIC for the provisioning network on the native VLAN and tagged VLANs that use subnets for the different overcloud network types. Dual NIC configuration - One NIC for the provisioning network and the other NIC for the external network. Dual NIC configuration - One NIC for the provisioning network on the native VLAN, and the other NIC for tagged VLANs that use subnets for different overcloud network types. Multiple NIC configuration - Each NIC uses a subnet for a different overcloud network type. For more information on the networking requirements, see Preparing your undercloud networking in Installing and managing Red Hat OpenStack Platform with director .

Commands:
8.8. Other XFS File System Utilities Red Hat Enterprise Linux 6 also features other utilities for managing XFS file systems: xfs_fsr Used to defragment mounted XFS file systems. When invoked with no arguments, xfs_fsr defragments all regular files in all mounted XFS file systems. This utility also allows users to suspend a defragmentation at a specified time and resume from where it left off later. In addition, xfs_fsr also allows the defragmentation of only one file, as in xfs_fsr /path/to/file . Red Hat advises against periodically defragmenting an entire file system, as this is normally not warranted. xfs_bmap Prints the map of disk blocks used by files in an XFS filesystem. This map lists each extent used by a specified file, as well as regions in the file with no corresponding blocks (that is, holes). xfs_info Prints XFS file system information. xfs_admin Changes the parameters of an XFS file system. The xfs_admin utility can only modify parameters of unmounted devices or file systems. xfs_copy Copies the contents of an entire XFS file system to one or more targets in parallel. The following utilities are also useful in debugging and analyzing XFS file systems: xfs_metadump Copies XFS file system metadata to a file. The xfs_metadump utility should only be used to copy unmounted, read-only, or frozen/suspended file systems; otherwise, generated dumps could be corrupted or inconsistent. xfs_mdrestore Restores an XFS metadump image (generated using xfs_metadump ) to a file system image. xfs_db Debugs an XFS file system. For more information about these utilities, refer to their respective man pages.

Commands:
1.3. Resource Controllers in Linux Kernel A resource controller, also called a cgroup subsystem, represents a single resource, such as CPU time or memory. The Linux kernel provides a range of resource controllers, that are mounted automatically by systemd . Find the list of currently mounted resource controllers in /proc/cgroups , or use the lssubsys monitoring tool. In Red Hat Enterprise Linux 7, systemd mounts the following controllers by default: Available Controllers in Red Hat Enterprise Linux 7 blkio - sets limits on input/output access to and from block devices; cpu - uses the CPU scheduler to provide cgroup tasks access to the CPU. It is mounted together with the cpuacct controller on the same mount; cpuacct - creates automatic reports on CPU resources used by tasks in a cgroup. It is mounted together with the cpu controller on the same mount; cpuset - assigns individual CPUs (on a multicore system) and memory nodes to tasks in a cgroup; devices - allows or denies access to devices for tasks in a cgroup; freezer - suspends or resumes tasks in a cgroup; memory - sets limits on memory use by tasks in a cgroup and generates automatic reports on memory resources used by those tasks; net_cls - tags network packets with a class identifier ( classid ) that allows the Linux traffic controller (the tc command) to identify packets originating from a particular cgroup task. A subsystem of net_cls , the net_filter (iptables) can also use this tag to perform actions on such packets. The net_filter tags network sockets with a firewall identifier ( fwid ) that allows the Linux firewall (the iptables command) to identify packets (skb->sk) originating from a particular cgroup task; perf_event - enables monitoring cgroups with the perf tool; hugetlb - allows to use virtual memory pages of large sizes and to enforce resource limits on these pages. The Linux kernel exposes a wide range of tunable parameters for resource controllers that can be configured with systemd . See the kernel documentation (list of references in the Controller-Specific Kernel Documentation section) for detailed description of these parameters.

Commands:
Chapter 2. Accessing the Fuse Console for Spring Boot 2.x You can access the Fuse Console for a standalone Fuse Spring Boot 2.x distribution. Procedure Add the following dependency to your Fuse application's pom.xml file: Note that you do not need to specify the exact version because it is provided by the Maven BOM. Edit the src/main/resources/application.properties file: Set the following properties: management.endpoints.web.exposure.include=hawtio,jolokia hawtio.authenticationEnabled=false management.endpoint.hawtio.enabled=true management.endpoint.jolokia.enabled=true Optionally, set the management.endpoints.web.base-path property. By default for Spring Boot 2.x, the Fuse Console's URL includes the context path ( /actuator ) of the management endpoints. For example: http://localhost:10001/actuator/hawtio/index.html To change this default URL, for example to specify http://localhost:10001/hawtio , set the management.endpoints.web.base-path property as shown here: management.endpoints.web.base-path=/ Your application.properties settings should look similar to the following example: Note By default, authentication for the Fuse Console on Spring Boot is disabled. Optionally, you can enable authentication by writing code specific to your Fuse Console distribution. Here is an example that you can use for guidance: https://github.com/hawtio/hawtio/tree/master/examples/springboot-authentication Run the Fuse application: To determine the port number for the Fuse Console URL, obtain the management.server.port value by looking at the value set in the src/main/resources/application.properties file. For example: To open the Fuse Console in a browser, use the following URL syntax where nnnnn is the value of the management.server.port property: http://localhost:nnnnn/actuator/hawtio For example, if the management.server.port property value is 10001 and you have not set the management.endpoints.web.base-path property then the URL is: http://localhost:10001/actuator/hawtio/index.html

Commands:
<dependency> <groupId>io.hawt</groupId> <artifactId>hawtio-springboot</artifactId> </dependency>
ports server.port=8080 management.server.port=10001 enable management endpoints for healthchecks and hawtio management.endpoints.enabled-by-default = false management.endpoint.hawtio.enabled = true management.endpoint.jolokia.enabled = true management.endpoints.health.enabled = true management.health.defaults.enabled=false camel.health.enabled=false camel.health.indicator.enabled=true management.endpoints.web.exposure.include=hawtio,jolokia hawtio.authenticationEnabled=false change the URL so that it does not include the actuator folder management.endpoints.web.base-path=/
mvn spring-boot:run
management.server.port = 10001
3.3.2. Enabling the IP Port for luci To allow client computers to communicate with a computer that runs luci (the Conga user interface server), you must enable the IP port assigned to luci . At each computer that runs luci , enable the IP port according to Table 3.2, "Enabled IP Port on a Computer That Runs luci " . Note If a cluster node is running luci , port 11111 should already have been enabled. Table 3.2. Enabled IP Port on a Computer That Runs luci IP Port Number Protocol Component 8084 TCP luci ( Conga user interface server) As of the Red Hat Enterprise Linux 6.1 release, which enabled configuration by means of the /etc/sysconfig/luci file, you can specifically configure the only IP address luci is being served at. You can use this capability if your server infrastructure incorporates more than one network and you want to access luci from the internal network only. To do this, uncomment and edit the line in the file that specifies host . For example, to change the host setting in the file to 10.10.10.10, edit the host line as follows: For more information on the /etc/sysconfig/luci file, see Section 3.4, "Configuring luci with /etc/sysconfig/luci " .

Commands:
host = 10.10.10.10
2. More to Come The System Administrators Guide is part of Red Hat, Inc's growing commitment to provide useful and timely support to Red Hat Enterprise Linux users. As new tools and applications are released, this guide will be expanded to include them. 2.1. Send in Your Feedback If you find an error in the System Administrators Guide , or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla ( http://bugzilla.redhat.com/bugzilla/ ) against the component rh-sag . Be sure to mention the manual's identifier: By mentioning this manual's identifier, we know exactly which version of the guide you have. If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

Commands:
rh-sag
2.7. Hardware Considerations You should take the following hardware considerations into account when deploying a GFS2 file system. Use Higher Quality Storage Options GFS2 can operate on cheaper shared storage options, such as iSCSI or Fibre Channel over Ethernet (FCoE), but you will get better performance if you buy higher quality storage with larger caching capacity. Red Hat performs most quality, sanity, and performance tests on SAN storage with Fibre Channel interconnect. As a general rule, it is always better to deploy something that has been tested first. Test Network Equipment Before Deploying Higher quality, faster network equipment makes cluster communications and GFS2 run faster with better reliability. However, you do not have to purchase the most expensive hardware. Some of the most expensive network switches have problems passing multicast packets, which are used for passing fcntl locks (flocks), whereas cheaper commodity network switches are sometimes faster and more reliable. Red Hat recommends trying equipment before deploying it into full production.

Commands:
17.10. Creating a Virtual Network To create a virtual network on your system using the Virtual Machine Manager (virt-manager): Open the Virtual Networks tab from within the Connection Details menu. Click the Add Network button, identified by a plus sign (+) icon. For more information, see Section 17.9, "Managing a Virtual Network" . Figure 17.11. Virtual network configuration This will open the Create a new virtual network window. Click Forward to continue. Figure 17.12. Naming your new virtual network Enter an appropriate name for your virtual network and click Forward . Figure 17.13. Choosing an IPv4 address space Check the Enable IPv4 network address space definition check box. Enter an IPv4 address space for your virtual network in the Network field. Check the Enable DHCPv4 check box. Define the DHCP range for your virtual network by specifying a Start and End range of IP addresses. Figure 17.14. Choosing an IPv4 address space Click Forward to continue. If you want to enable IPv6, check the Enable IPv6 network address space definition . Figure 17.15. Enabling IPv6 Additional fields appear in the Create a new virtual network window. Figure 17.16. Configuring IPv6 Enter an IPv6 address in the Network field. If you want to enable DHCPv6, check the Enable DHCPv6 check box. Additional fields appear in the Create a new virtual network window. Figure 17.17. Configuring DHCPv6 (Optional) Edit the start and end of the DHCPv6 range. If you want to enable static route definitions, check the Enable Static Route Definition check box. Additional fields appear in the Create a new virtual network window. Figure 17.18. Defining static routes Enter a network address and the gateway that will be used for the route to the network in the appropriate fields. Click Forward . Select how the virtual network should connect to the physical network. Figure 17.19. Connecting to the physical network If you want the virtual network to be isolated, ensure that the Isolated virtual network radio button is selected. If you want the virtual network to connect to a physical network, select Forwarding to physical network , and choose whether the Destination should be Any physical device or a specific physical device. Also select whether the Mode should be NAT or Routed . If you want to enable IPv6 routing within the virtual network, check the Enable IPv6 internal routing/networking check box. Enter a DNS domain name for the virtual network. Click Finish to create the virtual network. The new virtual network is now available in the Virtual Networks tab of the Connection Details window.

Commands:
6.2.2. Advisory Ordering When the kind=Optional option is specified for an order constraint, the constraint is considered optional and only has an effect when both resources are stopping and/or starting. Any change in state of the first resource you specified has no effect on the second resource you specified. The following command configures an advisory ordering constraint for the resources named VirtualIP and dummy_resource ,

Commands:
pcs constraint order VirtualIP then dummy_resource kind=Optional