mtpti5iD/redhat-docs_dataset huggingface dataset:
Part II. Installing and configuring Red Hat Process Automation Manager on Red Hat JBoss EAP 7.4 This document describes how to install Red Hat Process Automation Manager on a Red Hat JBoss Enterprise Application Platform 7.4 instance. Prerequisites You have reviewed the information in Planning a Red Hat Process Automation Manager installation . You have installed the latest patch release of Red Hat JBoss Enterprise Application Platform 7.4. For information about installing Red Hat JBoss EAP, see the Red Hat JBoss Enterprise Application Platform installation guide .

Commands:
Appendix A. ApiBuilder Methods The following table outlines the key methods available to the ApiBuilder class used in V3 of the Java software development kit. Table A.1. ApiBuilder Methods Method Argument Type Description user String The name of the user with which to connect to the Manager. You must specify both the user name and domain, such as admin@internal . This method must be used together with the password method. password String The password of the user with which to connect to the Manager. sessionID String The identifier of a session with which to connect to the Manager. If you have already authenticated with the Manager and a session is available, you can specify this argument instead of specifying a user name and password. requestTimeout Integer The timeout, in seconds, to wait for responses to requests. If a request takes longer than this value to respond, the request is cancelled, and an exception is thrown. This argument is optional. sessionTimeout Integer The timeout, in minutes, after which an active session is destroyed if no requests are made to the Manager. This argument is optional. persistentAuth Boolean Enables or disables persistent authentication using cookies. This option is enabled by default, so this method is only required to disable this option. noHostVerification Boolean Enables or disables verification of the host name in the SSL certificate presented by the server where the Manager is hosted. By default, the identity of host names is verified, and the connection is rejected if the host name is not correct, so this method is only required to disable this option. keyStorePath String Specifies the location of a file containing the CA certificate used to verify the certificate presented by the server where the Manager is hosted. This method must be used together with the keyStorePassword method. keyStorePassword String The password used to access the keystore file specified in the keyStorePath method. filter Boolean Enables or disables filtering of objects based on the permissions of the user making the request. By default, this option is disabled, which allows any user to see all objects in the environment. This method is only required to restrict the objects in the environment to those visible to the user making the request. debug Boolean Enables or disables debug output. By default, this option is disabled.

Commands:
Part I. Preparing the RHEL installation Before installing Red Hat Enterprise Linux (RHEL), ensure that your system meets the necessary hardware and architecture requirements. Additionally, you may want to optimize your installation experience by customizing the installation media or creating a bootable medium tailored to your environment. Registration of your RHEL system to Red Hat provides access to updates and support, which can enhance the system's stability and security. Special attention may also be needed for systems using UEFI Secure Boot, particularly when installing or booting RHEL beta releases.

Commands:
Chapter 2. The Admin Tab The Admin tab provides an interface where administrative users can view usage and manage instances, volumes, flavors, images, projects, users, services, and quotas. Note The Admin tab displays in the main window only if you have logged in as a user with administrative privileges. The following options are available in the Admin tab: Table 2.1. System Panel Parameter Name Description Overview View basic reports. Resource Usage Use the following tabs to view the following usages: Usage Report - View the usage report. Stats - View the statistics of all resources. Hypervisors View the hypervisor summary. Host Aggregates View, create, and edit host aggregates. View the list of availability zones. Instances View, pause, resume, suspend, migrate, soft or hard reboot, and delete running instances that belong to users of some, but not all, projects. Also, view the log for an instance or access an instance using the console. Volumes View, create, edit, and delete volumes, and volume types. Flavors View, create, edit, view extra specifications for, and delete flavors. Flavors are the virtual hardware templates in OpenStack. Images View, create, edit properties for, and delete custom images. Networks View, create, edit properties for, and delete networks. Routers View, create, edit properties for, and delete routers. Floating IPs View allocated floating IP addresses for all projects. Defaults View and edit the default quotas (maximum limits) for resources in the environment. Metadata Definitions Import, view, and edit metadata definition namespaces, and associate the metadata definitions with specific resource types. System Information Contains the following tabs: Services - View a list of the services. Compute Services - View a list of all Compute services. Network Agents - View the network agents. Block Storage Services - View a list of all Block Storage services. Orchestration Services - View a list of all Orchestration services. 2.1. View Allocated Floating IP Addresses You can use the Floating IPs panel to view a list of allocated floating IP addresses. This information can also be accessed using the command line:

Commands:
nova list --all-tenants
A.4. Install and Configure HAProxy Perform the following procedure on your two HAProxy nodes: Install haproxy . Configure haproxy for SELinux and HTTP. Add the following lines: As root, assign the correct SELinux context and file permissions to the haproxy-http.xml file. If you intend to use HTTPS, configure haproxy for SELinux and HTTPS. Add the following lines: As root, assign the correct SELinux context and file permissions to the haproxy-https.xml file. If you intend to use HTTPS, generate keys for SSL. If you do not have a certificate, you may use a self-signed certificate. For information on generating keys and on self-signed certificates, see the Red Hat Enterprise Linux System Administrator's Guide . Finally, put the certificate and key into a PEM file. Configure HAProxy. The global and defaults sections of haproxy.cfg may remain unchanged. After the defaults sections, you will need to configure frontend and backend sections, as in the following example: Enable/start haproxy

Commands:
yum install haproxy
vim /etc/firewalld/services/haproxy-http.xml
<?xml version="1.0" encoding="utf-8"?> <service> <short>HAProxy-HTTP</short> <description>HAProxy load-balancer</description> <port protocol="tcp" port="80"/> </service>
cd /etc/firewalld/services restorecon haproxy-http.xml chmod 640 haproxy-http.xml
vim /etc/firewalld/services/haproxy-https.xml
<?xml version="1.0" encoding="utf-8"?> <service> <short>HAProxy-HTTPS</short> <description>HAProxy load-balancer</description> <port protocol="tcp" port="443"/> </service>
cd /etc/firewalld/services restorecon haproxy-https.xml chmod 640 haproxy-https.xml
cat example.com.crt example.com.key > example.com.pem cp example.com.pem /etc/ssl/private/
vim /etc/haproxy/haproxy.cfg
frontend http_web *:80 mode http default_backend rgw frontend rgw\u00ad-https bind <insert vip ipv4>:443 ssl crt /etc/ssl/private/example.com.pem default_backend rgw backend rgw balance roundrobin mode http server rgw1 10.0.0.71:80 check server rgw2 10.0.0.80:80 check
systemctl enable haproxy systemctl start haproxy
Chapter 6. Fixed Common Vulnerabilities and Exposures This section details Common Vulnerabilities and Exposures (CVEs) fixed in the AMQ Broker 7.9 release. ENTMQBR-4071 - CVE-2020-13956 httpclient: apache-httpclient: incorrect handling of malformed authority component in request URIs ENTMQBR-4677 - CVE-2021-21290 netty: Information disclosure via the local system temporary directory ENTMQBR-4775 - CVE-2020-27223 jetty: request containing multiple Accept headers with a large number of "quality" parameters may lead to DoS ENTMQBR-4779 - CVE-2021-3425 broker: Red Hat AMQ Broker: discloses JDBC username and password in the application log file ENTMQBR-4795 - CVE-2021-21295 netty: possible request smuggling in HTTP/2 due missing validation ENTMQBR-4829 - CVE-2021-21409 netty: Request smuggling via content-length header ENTMQBR-4907 - CVE-2021-28163 jetty-server: jetty: Symlink directory exposes webapp directory contents ENTMQBR-4911 - CVE-2021-28165 jetty-server: jetty: Resource exhaustion when receiving an invalid large TLS frame ENTMQBR-4912 - CVE-2021-28164 jetty-server: jetty: Ambiguous paths can access WEB-INF ENTMQBR-4960 - CVE-2021-29425 commons-io: apache-commons-io: Limited path traversal in Apache Commons IO 2.2 to 2.6 ENTMQBR-5118 - CVE-2021-28169 jetty-server: jetty: requests to the ConcatServlet and WelcomeFilter are able to access protected resources within the WEB-INF directory ENTMQBR-5165 - CVE-2021-34428 jetty-server: jetty: SessionListener can prevent a session from being invalidated breaking logout ENTMQBR-5229 - CVE-2021-20289 resteasy-jaxrs: resteasy: Error message exposes endpoint class information ENTMQBR-5250 - CVE-2021-34429 jetty-server: jetty: crafted URIs allow bypassing security constraints ENTMQBR-5398 - CVE-2021-3763 AMQ Broker 7: Incorrect privilege in Management Console

Commands:
5.3.3. Creating Volume Groups in a Cluster You create volume groups in a cluster environment with the vgcreate command, just as you create them on a single node. By default, volume groups created with CLVM on shared storage are visible to all computers that have access to the shared storage. It is possible, however, to create volume groups that are local, visible only to one node in the cluster, by using the -c n option of the vgcreate command. The following command, when executed in a cluster environment, creates a volume group that is local to the node from which the command was executed. The command creates a local volume named vg1 that contains physical volumes /dev/sdd1 and /dev/sde1 . You can change whether an existing volume group is local or clustered with the -c option of the vgchange command, which is described in Section 5.3.8, "Changing the Parameters of a Volume Group" . You can check whether an existing volume group is a clustered volume group with the vgs command, which displays the c attribute if the volume is clustered. The following command displays the attributes of the volume groups VolGroup00 and testvg1 . In this example, VolGroup00 is not clustered, while testvg1 is clustered, as indicated by the c attribute under the Attr heading. For more information on the vgs command, see Section 5.3.5, "Displaying Volume Groups" Section 5.8, "Customized Reporting for LVM" , and the vgs man page.

Commands:
vgcreate -c n vg1 /dev/sdd1 /dev/sde1
vgs VG #PV #LV #SN Attr VSize VFree VolGroup00 1 2 0 wz--n- 19.88G 0 testvg1 1 1 0 wz--nc 46.00G 8.00M
Chapter 4. 21 August 2024 This release includes the following new feature: Red Hat Ansible Lightspeed trial Existing Ansible users can now start a free 90-day Red Hat Ansible Lightspeed cloud service trial. You can create single-task and multitask recommendations, generate playbooks, and view playbook explanations with a trial account. To start your Red Hat Ansible Lightspeed trial, you need a trial or paid subscription to the Red Hat Ansible Automation Platform; however, you do not need a trial or paid subscription to IBM watsonx Code Assistant. For more information, see Starting a trial of Red Hat Ansible Lightspeed .

Commands:
1.3.2.3. Inherently Insecure Services Even the most vigilant organization can fall victim to vulnerabilities if the network services they choose are inherently insecure. For instance, there are many services developed under the assumption that they are used over trusted networks; however, this assumption fails as soon as the service becomes available over the Internet - which is itself inherently untrusted. One category of insecure network services are those that require unencrypted user names and passwords for authentication. Telnet and FTP are two such services. If packet sniffing software is monitoring traffic between the remote user and such a service user names and passwords can be easily intercepted. Inherently, such services can also more easily fall prey to what the security industry terms the man-in-the-middle attack. In this type of attack, an attacker redirects network traffic by tricking a cracked name server on the network to point to his machine instead of the intended server. Once someone opens a remote session to the server, the attacker's machine acts as an invisible conduit, sitting quietly between the remote service and the unsuspecting user capturing information. In this way an attacker can gather administrative passwords and raw data without the server or the user realizing it. Another category of insecure services include network file systems and information services such as NFS or NIS, which are developed explicitly for LAN usage but are, unfortunately, extended to include WANs (for remote users). NFS does not, by default, have any authentication or security mechanisms configured to prevent an attacker from mounting the NFS share and accessing anything contained therein. NIS, as well, has vital information that must be known by every computer on a network, including passwords and file permissions, within a plain text ASCII or DBM (ASCII-derived) database. An attacker who gains access to this database can then access every user account on a network, including the administrator's account. By default, Red Hat Enterprise Linux is released with all such services turned off. However, since administrators often find themselves forced to use these services, careful configuration is critical. Refer to Section 2.2, "Server Security" for more information about setting up services in a safe manner.

Commands:
A.3.2. Commands and Interfaces that Support udev Table A.2, "dmsetup Commands to Support udev" summarizes the dmsetup commands that support udev integration. Table A.2. dmsetup Commands to Support udev Command Description dmsetup udevcomplete Used to notify that udev has completed processing the rules and unlocks waiting process (called from within udev rules in 95-dm-notify.rules ). dmsetup udevcomplete_all Used for debugging purposes to manually unlock all waiting processes. dmsetup udevcookies Used for debugging purposes, to show all existing cookies (system-wide semaphores). dmsetup udevcreatecookie Used to create a cookie (semaphore) manually. This is useful to run more processes under one synchronization resource. dmsetup udevreleasecookie Used to wait for all udev processing related to all processes put under that one synchronization cookie. The dmsetup options that support udev integration are as follows. --udevcookie Needs to be defined for all dmsetup processes we would like to add into a udev transaction. It is used in conjunction with udevcreatecookie and udevreleasecookie : Besides using the --udevcookie option, you can just export the variable into an environment of the process: --noudevrules Disables udev rules. Nodes/symlinks will be created by libdevmapper itself (the old way). This option is for debugging purposes, if udev does not work correctly. --noudevsync Disables udev synchronization. This is also for debugging purposes. For more information on the dmsetup and its options, see the dmsetup (8) man page. The LVM commands support the following options that support udev integration: --noudevrules : as for the dmsetup command, disables udev rules. --noudevsync : as for the dmsetup command, disables udev synchronization. The lvm.conf file includes the following options that support udev integration: udev_rules : enables/disables udev_rules for all LVM2 commands globally. udev_sync : enables/disables udev synchronization for all LVM commands globally. For more information on the lvm.conf file options, see the inline comments in the lvm.conf file.

Commands:
COOKIE=USD(dmsetup udevcreatecookie) dmsetup command --udevcookie USDCOOKIE . dmsetup command --udevcookie USDCOOKIE . . dmsetup command --udevcookie USDCOOKIE . dmsetup udevreleasecookie --udevcookie USDCOOKIE
export DM_UDEV_COOKIE=USD(dmsetup udevcreatecookie) dmsetup command dmsetup command dmsetup command
Chapter 131. KafkaBridgeTemplate schema reference Used in: KafkaBridgeSpec Property Property type Description deployment DeploymentTemplate Template for Kafka Bridge Deployment . pod PodTemplate Template for Kafka Bridge Pods . apiService InternalServiceTemplate Template for Kafka Bridge API Service . podDisruptionBudget PodDisruptionBudgetTemplate Template for Kafka Bridge PodDisruptionBudget . bridgeContainer ContainerTemplate Template for the Kafka Bridge container. clusterRoleBinding ResourceTemplate Template for the Kafka Bridge ClusterRoleBinding. serviceAccount ResourceTemplate Template for the Kafka Bridge service account. initContainer ContainerTemplate Template for the Kafka Bridge init container.

Commands:
Chapter 11. Enabling encryption on a vSphere cluster You can encrypt your virtual machines after installing OpenShift Container Platform 4.14 on vSphere by draining and shutting down your nodes one at a time. While each virtual machine is shutdown, you can enable encryption in the vCenter web interface. 11.1. Encrypting virtual machines You can encrypt your virtual machines with the following process. You can drain your virtual machines, power them down and encrypt them using the vCenter interface. Finally, you can create a storage class to use the encrypted storage. Prerequisites You have configured a Standard key provider in vSphere. For more information, see Adding a KMS to vCenter Server . Important The Native key provider in vCenter is not supported. For more information, see vSphere Native Key Provider Overview . You have enabled host encryption mode on all of the ESXi hosts that are hosting the cluster. For more information, see Enabling host encryption mode . You have a vSphere account which has all cryptographic privileges enabled. For more information, see Cryptographic Operations Privileges . Procedure Drain and cordon one of your nodes. For detailed instructions on node management, see "Working with Nodes". Shutdown the virtual machine associated with that node in the vCenter interface. Right-click on the virtual machine in the vCenter interface and select VM Policies Edit VM Storage Policies . Select an encrypted storage policy and select OK . Start the encrypted virtual machine in the vCenter interface. Repeat steps 1-5 for all nodes that you want to encrypt. Configure a storage class that uses the encrypted storage policy. For more information about configuring an encrypted storage class, see "VMware vSphere CSI Driver Operator". 11.2. Additional resources Working with nodes vSphere encryption Requirements for encrypting virtual machines

Commands:
3.16. Host Networking Configurations Common types of networking configurations for virtualization hosts include: Bridge and NIC configuration. This configuration uses a bridge to connect one or more virtual machines (or guests) to the host's NIC. An example of this configuration is the automatic creation of the ovirtmgmt network when installing Red Hat Virtualization Manager. Then, during host installation, the Red Hat Virtualization Manager installs VDSM on the host. The VDSM installation process creates the ovirtmgmt bridge which obtains the host's IP address to enable communication with the Manager. Important Set all hosts in a cluster to use the same IP stack for their management network; either IPv4 or IPv6 only. Dual stack is not supported. Bridge, VLAN, and NIC configuration. A VLAN can be included in the bridge and NIC configuration to provide a secure channel for data transfer over the network and also to support the option to connect multiple bridges to a single NIC using multiple VLANs. Bridge, Bond, and VLAN configuration. A bond creates a logical link that combines the two (or more) physical Ethernet links. The resultant benefits include NIC fault tolerance and potential bandwidth extension, depending on the bonding mode. Multiple Bridge, Multiple VLAN, and NIC configuration. This configuration connects a NIC to multiple VLANs. For example, to connect a single NIC to two VLANs, the network switch can be configured to pass network traffic that has been tagged into one of the two VLANs to one NIC on the host. The host uses two VNICs to separate VLAN traffic, one for each VLAN. Traffic tagged into either VLAN then connects to a separate bridge by having the appropriate VNIC as a bridge member. Each bridge, in turn, connects to multiple virtual machines. Note You can also bond multiple NICs to facilitate a connection with multiple VLANs. Each VLAN in this configuration is defined over the bond comprising the multiple NICs. Each VLAN connects to an individual bridge and each bridge connects to one or more guests.

Commands:
Chapter 9. Creating a Keycloak realm for Ansible Automation Platform Create a realm to manage a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control. Procedure Navigate to Operator Installed Operators . Select the Red Hat Single Sign-On Operator project. Select the Keycloak Realm tab and click Create Keycloak Realm . On the Keycloak Realm form, select YAML view . Edit the YAML file as follows: kind: KeycloakRealm apiVersion: keycloak.org/v1alpha1 metadata: name: ansible-automation-platform-keycloakrealm namespace: rh-sso labels: app: sso realm: ansible-automation-platform spec: realm: id: ansible-automation-platform realm: ansible-automation-platform enabled: true displayName: Ansible Automation Platform instanceSelector: matchLabels: app: sso Field Description metadata.name Set a unique value in metadata for the name of the configuration resource (CR). metadata.namespace Set a unique value in metadata for the name of the configuration resource (CR). metadata.labels.app Set labels to a unique value. This is used when creating the client CR. metadata.labels.realm Set labels to a unique value. This is used when creating the client CR. spec.realm.id Set the realm name and id. These must be the same. spec.realm.realm Set the realm name and id. These must be the same. spec.realm.displayname Set the name to display. Click Create and wait for the process to complete.

Commands:
kind: KeycloakRealm apiVersion: keycloak.org/v1alpha1 metadata: name: ansible-automation-platform-keycloakrealm namespace: rh-sso labels: app: sso realm: ansible-automation-platform spec: realm: id: ansible-automation-platform realm: ansible-automation-platform enabled: true displayName: Ansible Automation Platform instanceSelector: matchLabels: app: sso