mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Overview of tested deployment models Red Hat tests Ansible Automation Platform 2.5 with a defined set of topologies to give you opinionated deployment options. Deploy all components of Ansible Automation Platform so that all features and capabilities are available for use without the need to take further action. Red Hat tests the installation of Ansible Automation Platform 2.5 based on a defined set of infrastructure topologies or reference architectures. Enterprise organizations can use one of the enterprise topologies for production deployments to ensure the highest level of uptime, performance, and continued scalability. Organizations or deployments that are resource constrained can use a growth topology. It is possible to install the Ansible Automation Platform on different infrastructure topologies and with different environment configurations. Red Hat does not fully test topologies outside of published reference architectures. Use a tested topology for all new deployments. 1.1. Installation and deployment models The following table outlines the different ways to install or deploy Ansible Automation Platform: Table 1.1. Ansible Automation Platform installation and deployment models Mode Infrastructure Description Tested topologies RPM Virtual machines and bare metal The RPM installer deploys Ansible Automation Platform on Red Hat Enterprise Linux by using RPMs to install the platform on host machines. Customers manage the product and infrastructure lifecycle. RPM growth topology RPM mixed growth topology RPM enterprise topology RPM mixed enterprise topology Containers Virtual machines and bare metal The containerized installer deploys Ansible Automation Platform on Red Hat Enterprise Linux by using Podman which runs the platform in containers on host machines. Customers manage the product and infrastructure lifecycle. Container growth topology Container enterprise topology Operator Red Hat OpenShift The Operator uses Red Hat OpenShift Operators to deploy Ansible Automation Platform within Red Hat OpenShift. Customers manage the product and infrastructure lifecycle. Operator growth topology Operator enterprise topology

Commands:
10.6. System Specifications List The installation program automatically detects and installs your computer's hardware and you do not usually need to supply the installation program with any specific details about your system. However, when performing certain types of installation, it is important to know specific details about your hardware. For this reason, it is recommended that you record the following system specifications for reference during the installation, depending on your installation type. If you plan to use a customized partition layout, record: The model numbers, sizes, types, and interfaces of the hard drives attached to the system. For example, Seagate ST3320613AS 320 GB on SATA0, Western Digital WD7500AAKS 750 GB on SATA1. This will allow you to identify specific hard drives during the partitioning process. If you are installing Red Hat Enterprise Linux as an additional operating system on an existing system, record: Information about the partitions used on the system. This information can include file system types, device node names, file system labels, and sizes. This will allow you to identify specific partitions during the partitioning process. Remember that different operating systems identify partitions and drives differently, therefore even if the other operating system is a Unix operating system, the device names can be reported by Red Hat Enterprise Linux differently. This information can usually be found by executing the equivalent of the mount command and blkid command and in the /etc/fstab file. If you have other operating systems already installed, the Red Hat Enterprise Linux 7 installation program attempts to automatically detect and configure to boot them. You can manually configure any additional operating systems if they are not detected properly. For more information, see Section 13.15.1, "Boot Loader Installation" . If you plan to install from an image on a local hard drive: The hard drive and directory that holds the image. If you plan to install from a network location: The make and model numbers of the network adapters on your system. For example, Netgear GA311. This will allow you to identify adapters when manually configuring the network. IP, DHCP, and BOOTP addresses Netmask Gateway IP address One or more name server IP addresses (DNS) The location of the installation source on an FTP server, HTTP (web) server, HTTPS (web) server, or NFS server. If any of these networking requirements or terms are unfamiliar to you, contact your network administrator for assistance. If you plan to install on an iSCSI target: The location of the iSCSI target. Depending on your network, you might also need a CHAP user name and password, and perhaps a reverse CHAP user name and password. If your computer is part of a domain: You should verify that the domain name will be supplied by the DHCP server. If not, you will need to input the domain name manually during installation.

Commands:
17.2.7. Additional Resources The following sources of information provide additional resources regarding BIND. 17.2.7.1. Installed Documentation BIND features a full range of installed documentation covering many different topics, each placed in its own subject directory. For each item below, replace version with the version of the bind package installed on the system: /usr/share/doc/bind- version / The main directory containing the most recent documentation. /usr/share/doc/bind- version /arm/ The directory containing the BIND 9 Administrator Reference Manual in HTML and SGML formats, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start. /usr/share/doc/bind- version /draft/ The directory containing assorted technical documents that review issues related to the DNS service, and propose some methods to address them. /usr/share/doc/bind- version /misc/ The directory designed to address specific advanced issues. Users of BIND version 8 should consult the migration document for specific changes they must make when moving to BIND 9. The options file lists all of the options implemented in BIND 9 that are used in /etc/named.conf . /usr/share/doc/bind- version /rfc/ The directory providing every RFC document related to BIND. There is also a number of man pages for the various applications and configuration files involved with BIND: man rndc The manual page for rndc containing the full documentation on its usage. man named The manual page for named containing the documentation on assorted arguments that can be used to control the BIND nameserver daemon. man lwresd The manual page for lwresd containing the full documentation on the lightweight resolver daemon and its usage. man named.conf The manual page with a comprehensive list of options available within the named configuration file. man rndc.conf The manual page with a comprehensive list of options available within the rndc configuration file. 17.2.7.2. Useful Websites http://www.isc.org/software/bind The home page of the BIND project containing information about current releases as well as a PDF version of the BIND 9 Administrator Reference Manual . 17.2.7.3. Related Books DNS and BIND by Paul Albitz and Cricket Liu; O'Reilly & Associates A popular reference that explains both common and esoteric BIND configuration options, and provides strategies for securing a DNS server. The Concise Guide to DNS and BIND by Nicolai Langfeldt; Que Looks at the connection between multiple network services and BIND, with an emphasis on task-oriented, technical topics.

Commands:
4.2. Application Restrictions There are aspects of virtualization which make it unsuitable for certain types of applications. Applications with high I/O throughput requirements should use the paravirtualized drivers for fully-virtualized guests. Without the paravirtualized drivers certain applications may be unpredictable under heavy I/O loads. The following applications should be avoided due to high I/O requirements: kdump server netdump server You should carefully evaluate applications and tools that heavily utilize I/O or those that require real-time performance. Consider the paravirtualized drivers or PCI device assignment for increased I/O performance. Refer to Chapter 10, KVM Paravirtualized (virtio) Drivers for more information on the paravirtualized drivers for fully virtualized guests. Refer to Chapter 12, PCI Device Assignment for more information on PCI device assignment. Applications suffer a small performance loss from running in virtualized environments. The performance benefits of virtualization through consolidating to newer and faster hardware should be evaluated against the potential application performance issues associated with using virtualization.

Commands:
Chapter 8. Configuring maximum transmission unit (MTU) settings 8.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 openstack network show <network_name> 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. 8.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): 8.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. Installing dynamic plugins in an air-gapped environment You can install external plugins in an air-gapped environment by setting up a custom NPM registry. You can configure the NPM registry URL and authentication information for dynamic plugin packages using a Helm chart. For dynamic plugin packages obtained through npm pack , you can use a .npmrc file. Using the Helm chart, add the .npmrc file to the NPM registry by creating a secret named dynamic-plugins-npmrc with the following content: apiVersion: v1 kind: Secret metadata: name: dynamic-plugins-npmrc type: Opaque stringData: .npmrc: | registry=<registry-url> //<registry-url>:_authToken=<auth-token> ...

Commands:
apiVersion: v1 kind: Secret metadata: name: dynamic-plugins-npmrc type: Opaque stringData: .npmrc: | registry=<registry-url> //<registry-url>:_authToken=<auth-token>
Chapter 2. Obtaining a manifest file You can obtain a subscription manifest in the Subscription Allocations section of Red Hat Subscription Management. After you obtain a subscription allocation, you can download its manifest file and upload it to activate Ansible Automation Platform. To begin, login to the Red Hat Customer Portal using your administrator user account and follow the procedures in this section. 2.1. Create a subscription allocation Creating a new subscription allocation allows you to set aside subscriptions and entitlements for a system that is currently offline or air-gapped. This is necessary before you can download its manifest and upload it to Ansible Automation Platform. Procedure From the Subscription Allocations page, click New Subscription Allocation . Enter a name for the allocation so that you can find it later. Select Type: Satellite 6.8 as the management application. Click Create . 2.2. Adding subscriptions to a subscription allocation Once an allocation is created, you can add the subscriptions you need for Ansible Automation Platform to run properly. This step is necessary before you can download the manifest and add it to Ansible Automation Platform. Procedure From the Subscription Allocations page, click on the name of the Subscription Allocation to which you would like to add a subscription. Click the Subscriptions tab. Click Add Subscriptions . Enter the number of Ansible Automation Platform Entitlement(s) you plan to add. Click Submit . Verification After your subscription has been accepted, subscription details are displayed. A status of Compliant indicates your subscription is in compliance with the number of hosts you have automated within your subscription count. Otherwise, your status will show as Out of Compliance , indicating you have exceeded the number of hosts in your subscription. Other important information displayed include the following: Hosts automated Host count automated by the job, which consumes the license count Hosts imported Host count considering all inventory sources (does not impact hosts remaining) Hosts remaining Total host count minus hosts automated 2.3. Downloading a manifest file After an allocation is created and has the appropriate subscriptions on it, you can download the manifest from Red Hat Subscription Management. Procedure From the Subscription Allocations page, click on the name of the Subscription Allocation to which you would like to generate a manifest. Click the Subscriptions tab. Click Export Manifest to download the manifest file. Note The file is saved to your default downloads folder and can now be uploaded to activate Red Hat Ansible Automation Platform .

Commands:
10.10. Automating the Installation with Kickstart Red Hat Enterprise Linux 7 offers a way to partially or fully automate the installation process using a Kickstart file . Kickstart files contain answers to all questions normally asked by the installation program, such as what time zone do you want the system to use, how should the drives be partitioned or which packages should be installed. Providing a prepared Kickstart file at the beginning of the installation therefore allows you to perform the entire installation (or parts of it) automatically, without need for any intervention from the user. This is especially useful when deploying Red Hat Enterprise Linux on a large number of systems at once. In addition to allowing you to automate the installation, Kickstart files also provide more options regarding software selection. When installing Red Hat Enterprise Linux manually using the graphical installation interface, your software selection is limited to pre-defined environments and add-ons. A Kickstart file allows you to install or remove individual packages as well. For instructions about creating a Kickstart file and using it to automate the installation, see Chapter 27, Kickstart Installations .

Commands:
33.5. Selecting the Printer Model and Finishing Once you have properly selected a printer queue type, you can choose either option: Select a Printer from database - If you select this option, choose the make of your printer from the list of Makes . If your printer make is not listed, choose Generic . Provide PPD file - A PostScript Printer Description (PPD) file may also be provided with your printer. This file is normally provided by the manufacturer. If you are provided with a PPD file, you can choose this option and use the browser bar below the option description to select the PPD file. Refer to Figure 33.7, "Selecting a Printer Model" . Figure 33.7. Selecting a Printer Model After choosing an option, click Forward to continue. Figure 33.7, "Selecting a Printer Model" appears. You now have to choose the corresponding model and driver for the printer. The recommended printed driver is automatically selected based on the printer model you chose. The print driver processes the data that you want to print into a format the printer can understand. Since a local printer is attached directly to your computer, you need a printer driver to process the data that is sent to the printer. If you have a PPD file for the device (usually provided by the manufacturer), you can select it by choosing Provide PPD file . You can then browse the filesystem for the PPD file by clicking Browse . 33.5.1. Confirming Printer Configuration The last step is to confirm your printer configuration. Click Apply to add the print queue if the settings are correct. Click Back to modify the printer configuration. After applying the changes, print a test page to ensure the configuration is correct. Refer to Section 33.6, "Printing a Test Page" for details.

Commands:
20.11. Injecting Non-maskable Interrupts The virsh inject-nmi domain injects a non-maskable interrupt (NMI) message to the guest virtual machine. This is used when response time is critical, such as during non-recoverable hardware errors. In addition, virsh inject-nmi is useful for triggering a crashdump in Windows guests. Example 20.20. How to inject an NMI to the guest virtual machine The following example sends an NMI to the guest1 virtual machine: # virsh inject-nmi guest1

Commands:
23.4. Configuring a User Name Hint Policy for Smart-card Authentication As an Identity Management administrator, you can configure a user name hint policy for smart cards linked with multiple accounts. 23.4.1. User Name Hints in Identity Management The user name hint policy configures Identity Management to prompt smart card users for their user name. When a user tries to authenticate with a smart card certificate that matches multiple user accounts in Identity Management, one of the following occurs: If the user name hint policy is enabled, the user is prompted for a user name and then can proceed with authentication. If the user name hint policy is disabled, the authentication fails without prompting. Identity Management adds the user name hint to applications that would by default prompt for a smart card PIN without asking for a user name. On Red Hat Enterprise Linux, this is currently only the Gnome Desktop Manager (GDM) login. Figure 23.14. User name hint in the Gnome Desktop Manager Identity Management does not add the user name hint to applications that ask for a user name by default, for example: The Identity Management web UI authentication, because the GUI always displays the Username field ssh authentication, because ssh uses the current user's login name or the name provided with the -l option or in the username@host format Console authentication, where the login name is always supplied In these situations, authentication with a certificate that matches multiple users is always allowed. 23.4.2. Enabling User Name Hints in Identity Management The Identity Management administrator sets the user name hint policy centrally. The policy applies to all hosts enrolled into the Identity Management domain. Perform these steps on any Identity Management system. Command Line: Enabling User Name Hints in Identity Management Log in as the Identity Management administrator: Enable user name hints by using the ipa certmapconfig-mod command with the --promptusername=True option. To disable user name hints, use the --promptusername=False option. Web UI: Enabling User Name Hints in Identity Management Click Authentication Certificate Identity Mapping Rules Certificate Identity Mapping Global Configuration . Select Prompt for the username , and click Save . Figure 23.15. Enabling user name hints in the web UI Additional Resources For details on the ipa certmapconfig-mod command, execute it with the --help option.

Commands:
kinit admin Password for admin@IDM.EXAMPLE.COM:
ipa certmapconfig-mod --promptusername=TRUE Prompt for the username: TRUE
Appendix A. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the AMQ Streams for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Installing packages with DNF To install a package and all the package dependencies, use: dnf install <package_name> To install a previously-downloaded package from a local directory, use: dnf install <path_to_download_package> Revised on 2024-08-12 11:04:46 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
2.7.5. Site-to-Site Single Tunnel VPN Using Libreswan Often, when a site-to-site tunnel is built, the gateways need to communicate with each other using their internal IP addresses instead of their public IP addresses. This can be accomplished using a single tunnel. If the left host, with host name west , has internal IP address 192.0.1.254 and the right host, with host name east , has internal IP address 192.0.2.254 , store the following configuration using a single tunnel to the /etc/ipsec.d/myvpn.conf file on both servers:

Commands:
conn myvpn leftid=@west.example.com leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== left=192.1.2.23 leftsourceip=192.0.1.254 leftsubnet=192.0.1.0/24 rightid=@east.example.com rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== right=192.1.2.45 rightsourceip=192.0.2.254 rightsubnet=192.0.2.0/24 auto=start authby=rsasig