mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Automation controller licensing, updates and support Automation controller is provided as part of your annual Red Hat Ansible Automation Platform subscription. Ansible is an open source software project and is licensed under the GNU General Public License version 3, as described in the Ansible Source Code You must have valid subscriptions attached before installing Ansible Automation Platform. For more information, see Attaching Subscriptions . 2.1. Trial and evaluation You require a license to run automation controller. You can start by using a free trial license. Trial licenses for Ansible Automation Platform are available at: https://www.redhat.com/en/products/trials?products=ansible Support is not included in a trial license or during an evaluation of the automation controller software. 2.2. Component licenses To view the license information for the components included in automation controller, refer to /usr/share/doc/automation-controller-<version>/README . where <version> refers to the version of automation controller you have installed. To view a specific license, refer to /usr/share/doc/automation-controller-<version>/*.txt . where * is the license file name to which you are referring. 2.3. Node counting in licenses The automation controller license defines the number of Managed Nodes that can be managed as part of a Red Hat Ansible Automation Platform subscription. A typical license says "License Count: 500", which sets the maximum number of Managed Nodes at 500. For more information on managed node requirements for licensing, see https://access.redhat.com/articles/3331481 . Note Ansible does not recycle node counts or reset automated hosts.

Commands:
Chapter 39. InternalServiceTemplate schema reference Used in: CruiseControlTemplate , KafkaBridgeTemplate , KafkaClusterTemplate , KafkaConnectTemplate , ZookeeperClusterTemplate Property Property type Description metadata MetadataTemplate Metadata applied to the resource. ipFamilyPolicy string (one of [RequireDualStack, SingleStack, PreferDualStack]) Specifies the IP Family Policy used by the service. Available options are SingleStack , PreferDualStack and RequireDualStack . SingleStack is for a single IP family. PreferDualStack is for two IP families on dual-stack configured clusters or a single IP family on single-stack clusters. RequireDualStack fails unless there are two IP families on dual-stack configured clusters. If unspecified, OpenShift will choose the default value based on the service type. ipFamilies string (one or more of [IPv6, IPv4]) array Specifies the IP Families used by the service. Available options are IPv4 and IPv6 . If unspecified, OpenShift will choose the default value based on the ipFamilyPolicy setting.

Commands:
18.2. Bridged Mode When using Bridged mode , all of the guest virtual machines appear within the same subnet as the host physical machine. All other physical machines on the same physical network are aware of the virtual machines, and can access the virtual machines. Bridging operates on Layer 2 of the OSI networking model. It is possible to use multiple physical interfaces on the hypervisor by joining them together with a bond. The bond is then added to a bridge and then guest virtual machines are added onto the bridge as well. However, the bonding driver has several modes of operation, and only a few of these modes work with a bridge where virtual guest machines are in use. Figure 18.2. Virtual network switch in bridged mode Warning The only bonding modes that should be used with a guest virtual machine are Mode 1, Mode 2, and Mode 4. Under no circumstances should Modes 0, 3, 5, or 6 be used. It should also be noted that mii-monitoring should be used to monitor bonding modes as arp-monitoring does not work. For more information on bonding modes, refer to the knowledgebase article on bonding modes , or The Red Hat Enterprise Linux 6 Deployment Guide . For a detailed explanation of bridge_opts parameters, see the Red Hat Virtualization Administration Guide .

Commands:
5.2. Creating a Striped Logical Volume This example procedure creates an LVM striped logical volume called striped_logical_volume that stripes data across the disks at /dev/sda1 , /dev/sdb1 , and /dev/sdc1 . Label the disks you will use in the volume group as LVM physical volumes with the pvcreate command. Warning This command destroys any data on /dev/sda1 , /dev/sdb1 , and /dev/sdc1 . Create the volume group volgroup01 . The following command creates the volume group volgroup01 . You can use the vgs command to display the attributes of the new volume group. Create a striped logical volume from the volume group you have created. The following command creates the striped logical volume striped_logical_volume from the volume group volgroup01 . This example creates a logical volume that is 2 gigabytes in size, with three stripes and a stripe size of 4 kilobytes. Create a file system on the striped logical volume. The following command creates a GFS2 file system on the logical volume. The following commands mount the logical volume and report the file system disk space usage.

Commands:
pvcreate /dev/sda1 /dev/sdb1 /dev/sdc1 Physical volume "/dev/sda1" successfully created Physical volume "/dev/sdb1" successfully created Physical volume "/dev/sdc1" successfully created
vgcreate volgroup01 /dev/sda1 /dev/sdb1 /dev/sdc1 Volume group "volgroup01" successfully created
vgs VG #PV #LV #SN Attr VSize VFree volgroup01 3 0 0 wz--n- 51.45G 51.45G
lvcreate -i 3 -I 4 -L 2G -n striped_logical_volume volgroup01 Rounding size (512 extents) up to stripe boundary size (513 extents) Logical volume "striped_logical_volume" created
mkfs.gfs2 -p lock_nolock -j 1 /dev/volgroup01/striped_logical_volume This will destroy any data on /dev/volgroup01/striped_logical_volume. Are you sure you want to proceed? [y/n] y Device: /dev/volgroup01/striped_logical_volume Blocksize: 4096 Filesystem Size: 492484 Journals: 1 Resource Groups: 8 Locking Protocol: lock_nolock Lock Table: Syncing All Done
mount /dev/volgroup01/striped_logical_volume /mnt df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 13902624 1656776 11528232 13% / /dev/hda1 101086 10787 85080 12% /boot tmpfs 127880 0 127880 0% /dev/shm /dev/volgroup01/striped_logical_volume 1969936 20 1969916 1% /mnt
B.39.3. RHSA-2011:0200 - Important: krb5 security update Updated krb5 packages that fix three security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Kerberos is a network authentication system which allows clients and servers to authenticate to each other using symmetric encryption and a trusted third-party, the Key Distribution Center (KDC). CVE-2011-0282 A NULL pointer dereference flaw was found in the way the MIT Kerberos KDC processed principal names that were not null terminated, when the KDC was configured to use an LDAP back end. A remote attacker could use this flaw to crash the KDC via a specially-crafted request. CVE-2011-0281 A denial of service flaw was found in the way the MIT Kerberos KDC processed certain principal names when the KDC was configured to use an LDAP back end. A remote attacker could use this flaw to cause the KDC to hang via a specially-crafted request. CVE-2010-4022 A denial of service flaw was found in the way the MIT Kerberos V5 slave KDC update server (kpropd) processed certain update requests for KDC database propagation. A remote attacker could use this flaw to terminate the kpropd daemon via a specially-crafted update request. Red Hat would like to thank the MIT Kerberos Team for reporting the CVE-2011-0282 and CVE-2011-0281 issues. Upstream acknowledges Kevin Longfellow of Oracle Corporation as the original reporter of the CVE-2011-0281 issue. All krb5 users should upgrade to these updated packages, which contain backported patches to correct these issues. After installing the updated packages, the krb5kdc daemon will be restarted automatically.

Commands:
12.5. Storage Types 12.5.1. Storage Types The storage element contains a type element, which is an enumerated value found under the capabilities collection. The storage element also contains additional elements specific to each storage type . The few sections examine these additional storage type elements. 12.5.2. NFS Storage The following table contains nfs specific elements in a storage description. Table 12.2. NFS specific elements Element Type Description Properties address string The host name or IP address of the NFS server. path string The path of NFS mountable directory on the server. 12.5.3. PosixFS Storage The following table contains posixfs specific elements in a storage description. Table 12.3. PosixFS specific elements Element Type Description Properties address string The host name or IP address of the PosixFS server. path string The path of PosixFS mountable directory on the server. vfs_type string The Linux-supported file system type of the PosixFS share. mount_options string The options for mounting the PosixFS share. 12.5.4. iSCSI and FCP Storage The following table contains iscsi and fcp specific elements in a storage description. Table 12.4. iSCSI and FCP specific elements Element Type Description Properties logical_unit id= complex The id of the logical unit. A storage domain also accepts multiple iSCSI or FCP logical units. override_luns Boolean Defines whether to replace all logical unit settings with new settings. Set to true to override. The logical_unit contains a set of sub-elements. Table 12.5. Logical unit elements Element Type Description Properties address string The address of the server containing the storage device. port integer The port number of the server. target string The target IQN for the storage device. username string A CHAP user name for logging into a target. password string A CHAP password for logging into a target. serial string The serial ID for the target. vendor_id string The vendor name for the target. product_id string The product code for the target. lun_mapping integer The Logical Unit Number device mapping for the target. In the case of iSCSI, if a logical_unit description also contains details of the iSCSI target with the LUN in question, the target performs an automatic login when the storage domain is created. 12.5.5. LocalFS Storage The localfs specific elements in a storage description are: Table 12.6. Localfs specific elements Element Type Description Properties path string The path of local storage domain on the host. A localfs storage domain requires a data center with storage_type set to localfs . This data center only contains a single host cluster, and the host cluster only contains a single host.

Commands:
8.3.3. Hardware and Software Availability Your disaster recovery plan must include methods of procuring the necessary hardware and software for operations at the backup site. A professionally-managed backup site may already have everything you need (or you may need to arrange the procurement and delivery of specialized materials the site does not have available); on the other hand, a cold backup site means that a reliable source for every single item must be identified. Often organizations work with manufacturers to craft agreements for the speedy delivery of hardware and/or software in the event of a disaster.

Commands:
5.23. certmonger 5.23.1. RHBA-2012:0833 - certmonger bug fix and enhancement update Updated certmonger packages that fix multiple bugs and add multiple enhancements are now available for Red Hat Enterprise Linux 6. The certmonger daemon monitors certificates which have been registered with it, and as a certificate's not-valid-after date approaches, the daemon can optionally attempt to obtain a fresh certificate from a supported CA. The certmonger packages have been upgraded to upstream version 0.56, which provides a number of bug fixes and enhancements over the version. (BZ# 789153 ) Bug Fixes BZ# 765599 Prior to this update, one of the examples provided in the getting-started.txt file did not work as expected if the daemon was prevented from accessing files in user-specified locations, for example by the SELinux policy. With this update, this problem is now documented in the getting-started.txt file. BZ# 765600 Prior to this update, the certmonger daemon was not configured to start by default when the package was installed. This update enables the certmonger service by default. BZ# 796542 Prior to this update, the "getcert" command could under certain circumstances, display the misleading error message "invalid option" when an option that required an argument was used and the argument was not specified. This update modifies the error code so that the correct message is now sent. Enhancement BZ# 766167 Prior to this update, newly added certificates were not automatically visible. To see these certificates, servers had to be manually restarted. This update adds the emission of D-Bus signals over the message bus to allow applications to perform the actions they need to use a new certificate. Also, the new "-C" option was added to invoke a user-specified command. All users of certmonger are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 9. Enabling OCI support with the Red Hat Quay Operator Use the following procedure to configure Open Container Initiative (OCI) support for Red Hat Quay. Procedure Create a quay-config-bundle YAML file that includes the following information: apiVersion: v1 stringData: config.yaml: | FEATURE_GENERAL_OCI_SUPPORT: true kind: Secret metadata: name: quay-config-bundle namespace: quay-enterprise type: Opaque Enter the following command to create a the quay-config-bundle object in the appropriate namespace, passing in the necessary properties to enable OCI support. For example: USD oc create -n quay-enterprise -f quay-config-bundle.yaml In your quay-registry.yaml file, reference the secret for the spec.configBundleSecret field. For example: apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: quay-config-bundle Additional resources For more information, see OCI Support and Red Hat Quay

Commands:
apiVersion: v1 stringData: config.yaml: | FEATURE_GENERAL_OCI_SUPPORT: true kind: Secret metadata: name: quay-config-bundle namespace: quay-enterprise type: Opaque
oc create -n quay-enterprise -f quay-config-bundle.yaml
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: quay-config-bundle
19.3. Using volume_key in a larger organization In a larger organization, using a single password known by every system administrator and keeping track of a separate password for each system is impractical and a security risk. To counter this, volume_key can use asymmetric cryptography to minimize the number of people who know the password required to access encrypted data on any computer. This section will cover the procedures required for preparation before saving encryption keys, how to save encryption keys, restoring access to a volume, and setting up emergency passphrases. 19.3.1. Preparation for saving encryption keys In order to begin saving encryption keys, some preparation is required. Procedure 19.3. Preparation Create an X509 certificate/private pair. Designate trusted users who are trusted not to compromise the private key. These users will be able to decrypt the escrow packets. Choose which systems will be used to decrypt the escrow packets. On these systems, set up an NSS database that contains the private key. If the private key was not created in an NSS database, follow these steps: Store the certificate and private key in an PKCS#12 file. Run: At this point it is possible to choose an NSS database password. Each NSS database can have a different password so the designated users do not need to share a single password if a separate NSS database is used by each user. Run: Distribute the certificate to anyone installing systems or saving keys on existing systems. For saved private keys, prepare storage that allows them to be looked up by machine and volume. For example, this can be a simple directory with one subdirectory per machine, or a database used for other system management tasks as well.

Commands:
certutil -d /the/nss/directory -N
pk12util -d /the/nss/directory -i the-pkcs12-file
Chapter 4. Creating Red Hat Gluster Storage volumes using the Administration Portal Prerequisites This task assumes you have raw unused storage devices attached to your hyperconverged hosts. Task Log in to the Administration Portal. Configure your local storage as a Red Hat Gluster Storage brick. Click Compute Hosts and click on the name of the host to use. Click the Storage Devices subtab and select the device. Click Create Brick to open the Create Brick window. The Create Brick window Enter a Name for the brick. Verify or correct the suggested Mount Point . If the underlying storage uses RAID, enter the number of physical disks in the RAID device and confirm the RAID type. Click OK . A new thin-provisioned logical volume is created on the specified storage device, with all settings appropriate for use with Red Hat Gluster Storage. Configure a Red Hat Gluster Storage volume. Click Storage Volumes . Click New to open the New Volume window. The New Volume window Select the cluster that contains your bricks. Enter a Name for the volume. Set the Type of volume to create. To use local storage without high availability, choose Distribute . See Setting Up Storage Volumes in the Red Hat Gluster Storage Administration Guide for more information about volume types. Click Add Bricks and select your existing storage as a brick for this volume. The Add Bricks window Optionally, for enhanced security, specify the IP addresses or hostnames of all hosts in the cluster in the Allow Access From field. Check the Optimize for virt store checkbox to configure the volume for storing virtual machine images. Click OK . See the Red Hat Virtualization 4.4 Administration Guide or the Red Hat Gluster Storage 3.5 Administration Guide for more information about managing Red Hat Gluster Storage.

Commands:
7.8. Creating Audit Reports The aureport utility allows you to generate summary and columnar reports on the events recorded in Audit log files. By default, all audit.log files in the /var/log/audit/ directory are queried to create the report. You can specify a different file to run the report against using the aureport options -if file_name command. Example 7.7. Using aureport to generate Audit reports To generate a report for logged events in the past three days excluding the current example day, use the following command: To generate a report of all executable file events, use the following command: To generate a summary of the executable file event report above, use the following command: To generate a summary report of failed events for all users, use the following command: To generate a summary report of all failed login attempts per each system user, use the following command: To generate a report from an ausearch query that searches all file access events for user 500 , use the following command: To generate a report of all Audit files that are queried and the time range of events they include, use the following command: For a full listing of all aureport options, see the aureport (8) man page.

Commands:
~]# aureport --start 04/08/2013 00:00:00 --end 04/11/2013 00:00:00
~]# aureport -x
~]# aureport -x --summary
~]# aureport -u --failed --summary -i
~]# aureport --login --summary -i
~]# ausearch --start today --loginuid 500 --raw | aureport -f --summary
~]# aureport -t
Appendix A. Appendix A.1. Compute CPU and memory calculator The following subsections describe how the OpenStack Workflow calculates the optimal settings for CPU and memory. A.1.1. NovaReservedHostMemory The NovaReservedHostMemory parameter sets the amount of memory (in MB) to reserve for the host node. To determine an appropriate value for hyper-converged nodes, assume that each OSD consumes 3 GB of memory. Given a node with 256 GB memory and 10 OSDs, you can allocate 30 GB of memory for Ceph, leaving 226 GB for Compute. With that much memory a node can host, for example, 113 instances using 2 GB of memory each. However, you still need to consider additional overhead per instance for the hypervisor . Assuming this overhead is 0.5 GB, the same node can only host 90 instances, which accounts for the 226 GB divided by 2.5 GB. The amount of memory to reserve for the host node (that is, memory the Compute service should not use) is: (In * Ov) + (Os * RA) Where: In : number of instances Ov : amount of overhead memory needed per instance Os : number of OSDs on the node RA : amount of RAM that each OSD should have With 90 instances, this give us (90*0.5) + (10*3) = 75 GB. The Compute service expects this value in MB, namely 75000. The following Python code provides this computation: A.1.2. cpu_allocation_ratio The Compute scheduler uses cpu_allocation_ratio when choosing which Compute nodes on which to deploy an instance. By default, this is 16.0 (as in, 16:1). This means if there are 56 cores on a node, the Compute scheduler will schedule enough instances to consume 896 vCPUs on a node before considering the node unable to host any more. To determine a suitable cpu_allocation_ratio for a hyper-converged node, assume each Ceph OSD uses at least one core (unless the workload is I/O-intensive, and on a node with no SSD). On a node with 56 cores and 10 OSDs, this would leave 46 cores for Compute. If each instance uses 100 per cent of the CPU it receives, then the ratio would simply be the number of instance vCPUs divided by the number of cores; that is, 46 / 56 = 0.8. However, since instances do not normally consume 100 per cent of their allocated CPUs, you can raise the cpu_allocation_ratio by taking the anticipated percentage into account when determining the number of required guest vCPUs. So, if we can predict that instances will only use 10 per cent (or 0.1) of their vCPU, then the number of vCPUs for instances can be expressed as 46 / 0.1 = 460. When this value is divided by the number of cores (56), the ratio increases to approximately 8. The following Python code provides this computation:

Commands:
left_over_mem = mem - (GB_per_OSD * osds) number_of_guests = int(left_over_mem / (average_guest_size + GB_overhead_per_guest)) nova_reserved_mem_MB = MB_per_GB * ( (GB_per_OSD * osds) + (number_of_guests * GB_overhead_per_guest))
cores_per_OSD = 1.0 average_guest_util = 0.1 # 10% nonceph_cores = cores - (cores_per_OSD * osds) guest_vCPUs = nonceph_cores / average_guest_util cpu_allocation_ratio = guest_vCPUs / cores