mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Installing automation hub With the installation of the Ansible Automation Platform operator completed, the following steps install automation hub within a Red Hat OpenShift cluster. Note The resource requests and limits values are specific to this reference environment. Ensure to read the Chapter 3, Before you start section to properly calculate the values for your Red Hat OpenShift environment. Warning When an instance of automation hub is removed, the associated Persistent Volume Claims (PVCs) are not automatically deleted. This can cause issues during migration if the new deployment has the same name as the deployment. It is recommended to remove old PVCs prior to deploying a new automation hub instance in the same namespace. The steps to remove deployment PVCs can be found within Appendix B, Delete existing PVCs from AAP installations . Note Automation hub requires ReadWriteMany file-based storage, Azure Blob storage or Amazon S3-compliant storage for operation to ensure multiple pods can access shared content, such as collections. Log in to the Red Hat OpenShift web console using your cluster credentials. In the left-hand navigation menu, select Operators Installed Operators , select Ansible Automation Platform . Navigate to the Automation Hub tab, then click Create AutomationHub . Within the Form view provide a Name , e.g. my-automation-hub Within the Storage type , select your ReadWriteMany compliant storage. Note This reference environment uses Amazon S3 as its ReadWriteMany storage. Details to create an Amazon S3 bucket can be found in Appendix D, Create an Amazon S3 bucket . Provide S3 storage secret . Details on how to create within Appendix E, Creating an AWS S3 Secret . Select the Advanced configuration to expand the additional options. Within PostgreSQL container storage requirements (when using a managed instance) set storage limit to 50Gi set storage requests to 8Gi Within PostgreSQL container resource requirements (when using a managed instance) Limits: CPU cores: 500m, Memory: 1Gi Requests: CPU cores: 200m, Memory: 1Gi Within Redis deployment configuration , select Advanced configuration Select In-memory data store resource requirements Limits: CPU cores: 250m, Memory: 200Mi Requests: CPU cores: 100m, Memory: 200Mi Within API server configuration , select Advanced configuration Select API server resource requirements Limits: CPU cores: 250m, Memory: 400Mi Requests: CPU cores: 150m, Memory: 400Mi Within Content server configuration , select Advanced configuration Select Content server resource requirements Limits: CPU cores: 250m, Memory: 400Mi Requests: CPU cores: 100m, Memory: 400Mi Within Worker configuration , select Advanced configuration Select Worker resource requirements Limits: CPU cores: 1000m, Memory: 3Gi Requests: CPU cores: 500m, Memory: 3Gi Click the Create button

Commands:
Chapter 4. HOME: Checking connected clusters The homepage offers a snapshot of connected Kafka clusters, providing information on the Kafka version and associated project for each cluster. To find more information, log in to a cluster. 4.1. Logging in to a Kafka cluster The console supports authenticated user login to a Kafka cluster using SCRAM-SHA-512 and OAuth 2.0 authentication mechanisms. For secure login, authentication must be configured in Streams for Apache Kafka. Note If authentication is not set up for a Kafka cluster or the credentials have been provided using the Kafka sasl.jaas.config property (which defines SASL authentication settings) in the console configuration, you can log in anonymously to the cluster without authentication. Prerequisites You must have access to an OpenShift Container Platform cluster. The console must be deployed and set up to connect to a Kafka cluster . For secure login, you must have appropriate authentication settings for the Kafka cluster and user. SCRAM-SHA-512 settings Listener authentication set to scram-sha-512 in Kafka.spec.kafka.listeners[*].authentication . Username and password configured in KafkaUser.spec.authentication . OAuth 2.0 settings An OAuth 2.0 authorization server with client definitions for the Kafka cluster and users. Listener authentication set to oauth in Kafka.spec.kafka.listeners[*].authentication . For more information on configuring authentication, see the Streams for Apache Kafka documentation . Procedure From the homepage, click Login to cluster for a selected Kafka cluster. Enter login credentials depending on the authentication method used. For SCRAM-SHA-512, enter the username and password associated with the KafkaUser . For OAuth 2.0, provide a client ID and client secret that is valid for the OAuth provider configured for the Kafka listener. To end your session, click your username and then Logout or navigate back to the homepage.

Commands:
Chapter 1. Overview Read this document to understand how to create, configure, and allocate storage to core services or hosted applications in Red Hat OpenShift Data Foundation. Chapter 2, Storage classes shows you how to create custom storage classes. Chapter 5, Block pools provides you with information on how to create, update and delete block pools. Chapter 6, Configure storage for OpenShift Container Platform services shows you how to use OpenShift Data Foundation for core OpenShift Container Platform services. Chapter 8, Backing OpenShift Container Platform applications with OpenShift Data Foundation provides information about how to configure OpenShift Container Platform applications to use OpenShift Data Foundation. Adding file and object storage to an existing external OpenShift Data Foundation cluster Chapter 10, How to use dedicated worker nodes for Red Hat OpenShift Data Foundation provides information about how to use dedicated worker nodes for Red Hat OpenShift Data Foundation. Chapter 11, Managing Persistent Volume Claims provides information about managing Persistent Volume Claim requests, and automating the fulfillment of those requests. Chapter 12, Reclaiming space on target volumes shows you how to reclaim the actual available storage space. Chapter 14, Volume Snapshots shows you how to create, restore, and delete volume snapshots. Chapter 15, Volume cloning shows you how to create volume clones. Chapter 16, Managing container storage interface (CSI) component placements provides information about setting tolerations to bring up container storage interface component on the nodes.

Commands:
4.5. RESTful Service Description Language (RSDL) RESTful Service Description Language (RSDL) provides a description of the structure and elements in the REST API in one whole XML specification. Invoke the RSDL using the following request. This produces an XML document in the following format: Table 4.5. RSDL Structure Elements Element Description description A plain text description of the RSDL document. version The API version, including major release, minor release, build and revision . schema A link to the XML schema (XSD) file. links Defines each link in the API. Each link element contains the following a structure: Table 4.6. RSDL Link Structure Elements Element Description link A URI for API requests. Includes a URI attribute ( href ) and a relationship type attribute ( rel ). request Defines the request properties required for the link. http_method The method type to access this link. Includes the standard HTTP methods for REST API access: GET , POST , PUT and DELETE . headers Defines the headers for the HTTP request. Contains a series of header elements, which each contain a header name and value to define the header. body Defines the body for the HTTP request. Contains a resource type and a parameter_set , which contains a sets of parameter elements with attributes to define whether they are required for a request and the data type . The parameter element also includes a name element to define the Red Hat Virtualization Manager property to modify and also a further parameter_set subset if type is set to collection . response Defines the output for the HTTP request. Contains a type element to define the resource structure to output. Use the RSDL in your applications as a method to map all links and parameter requirements for controlling a Red Hat Virtualization environment.

Commands:
GET /ovirt-engine/api?rsdl HTTP/1.1 Accept: application/xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rsdl href="/ovirt-engine/api?rsdl" rel="rsdl"> <description>...</description> <version major="4" minor="0" build="0" revision="0"/> <schema href="/ovirt-engine/api?schema" rel="schema"> <name>...</name> <description>...</description> </schema> <links> <link href="/ovirt-engine/api/capabilities" rel="get"> </link> </links> </rsdl>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <rsdl href="/ovirt-engine/api?rsdl" rel="rsdl"> <links> <link href="/ovirt-engine/api/..." rel="..."> <request> <http_method>...</http_method> <headers> <header> <name>...</name> <value>...</value> </header> </headers> <body> <type>...</type> <parameters_set> <parameter required="..." type="..."> <name>...</name> </parameter> </parameters_set> </body> </request> <response> <type>...</type> </response> </link> </links> </rsdl>
Chapter 14. Enabling the Red Hat Virtualization Manager Repositories Register the system with Red Hat Subscription Manager, attach the Red Hat Virtualization Manager subscription, and enable Manager repositories. Procedure Register your system with the Content Delivery Network, entering your Customer Portal user name and password when prompted: Note If you are using an IPv6 network, use an IPv6 transition mechanism to access the Content Delivery Network and subscription manager. Find the Red Hat Virtualization Manager subscription pool and record the pool ID: Use the pool ID to attach the subscription to the system: Note To view currently attached subscriptions: To list all enabled repositories: Configure the repositories: Enable the pki-deps module. Enable version 12 of the postgresql module. Synchronize installed packages to update them to the latest available versions. Additional resources For information on modules and module streams, see the following sections in Installing , managing , and removing user-space components Module streams Selecting a stream before installation of packages Resetting module streams Switching to a later stream

Commands:
subscription-manager register
subscription-manager list --available
subscription-manager attach --pool=pool_id
subscription-manager list --consumed
yum repolist
subscription-manager repos --disable='*' --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
yum module -y enable pki-deps
yum module -y enable postgresql:12
yum distro-sync
Chapter 21. Parameter and Configuration Files on IBM Z The IBM Z architecture can use a customized parameter file to pass boot parameters to the kernel and the installation program. This section describes the contents of this parameter file. You need only read this section if you intend to change the shipped parameter file. You need to change the parameter file if you want to: install unattended with Kickstart. choose non-default installation settings that are not accessible through the installation program"s interactive user interface, such as rescue mode. The parameter file can be used to set up networking non-interactively before the installation program (loader and Anaconda ) starts. The kernel parameter file is limited to 895 characters plus an end-of-line character. The parameter file can be variable or fixed record format. Fixed record format increases the file size by padding each line up to the record length. Should you encounter problems with the installation program not recognizing all specified parameters in LPAR environments, you can try to put all parameters in one single line or start and end each line with a space character. The parameter file contains kernel parameters, such as ro , and parameters for the installation process, such as vncpassword=test or vnc . 21.1. Required Parameters The following parameters are required and must be included in the parameter file. They are also provided in the file generic.prm in directory images/ of the installation DVD: ro mounts the root file system, which is a RAM disk, read-only. ramdisk_size= size modifies the memory size reserved for the RAM disk to ensure that the Red Hat Enterprise Linux installation program fits within it. For example: ramdisk_size=40000 . The generic.prm file also contains the additional parameter cio_ignore=all,!condev . This setting speeds up boot and device detection on systems with many devices. The installation program transparently handles the activation of ignored devices. Important To avoid installation problems arising from cio_ignore support not being implemented throughout the entire stack, adapt the cio_ignore= parameter value to your system or remove the parameter entirely from your parameter file used for booting (IPL) the installation program.

Commands:
4.7. RHEA-2012:0981 - new packages: java-1.7.0-openjdk New java-1.7.0-openjdk packages that provide OpenJDK 7 are now available as a Technology Preview for Red Hat Enterprise Linux 6. [Updated 9 June 2012] This advisory has been updated to reflect the fact that java-1.7.0-openjdk is fully supported and no longer claims that java-1.7.0-openjdk is a Technology Preview feature. The packages included in this revised update have not been changed in any way from the packages included in the version of this advisory. The java-1.7.0-openjdk packages provide the OpenJDK 7 Java Runtime Environment and the OpenJDK 7 Java Software Development Kit. This enhancement update adds new java-1.7.0-openjdk package to Red Hat Enterprise Linux 6. (BZ# 803726 ) These packages do not replace the version of the OpenJDK (java-1.6.0-openjdk) if present. Users can safely install OpenJDK 7 in addition to OpenJDK 6. The system default version of Java can be configured using the 'alternatives' tool. All users who want to use java-1.7.0-openjdk should install these newly released packages, which add this enhancement.

Commands:
Chapter 3. Applying the RHEL release lock SAP supports SAP HANA with certain minor RHEL releases, for example RHEL 8.2. You need to apply a release lock to make sure your RHEL system is set to a certain minor release. For more information on which minor RHEL 8 releases are supported by SAP, see the SAP note 2235581 . Important Updating your RHEL system before applying a release lock will result in dependency errors and a possible upgrade to a RHEL 8 minor version that is not supported by SAP HANA. It is advised you run yum installations and updates only after the release lock is applied. Note that if you used redhat_sap.sap_rhsm ansible role to register and subscribe your RHEL server to RHEL for SAP Solutions repositories you can skip this step and proceed to Installing RHEL System Roles for SAP . For more information, see sap_rhsm section on the Ansible Galaxy portal. Prerequisites root access Procedure Clear the dnf cache: Set the release lock: Replace 8.x with the supported minor release of RHEL 8 (for example 8.2). Additional resources How to tie a system to a specific update of RHEL

Commands:
rm -rf /var/cache/dnf
subscription-manager release --set= 8.x
Chapter 15. Virtual File Systems and Disk Management 15.1. GVFS GVFS ( GNOME Virtual File System ) is an extension of the virtual file system interface provided by the libraries the GNOME Desktop is built on. GVFS provides complete virtual file system infrastructure and handles storage in the GNOME Desktop. GVFS uses addresses for full identification based on the URI (Uniform Resource Identifier) standard, syntactically similar to URL addresses used in web browsers. These addresses in form of schema://user@server/path are the key information determining the kind of service.

Commands:
19.4. Kerberos and PAM Currently, kerberized services do not make use of Pluggable Authentication Modules (PAM) - kerberized servers bypass PAM completely. However, applications that use PAM can make use of Kerberos for authentication if the pam_krb5 module (provided in the pam_krb5 package) is installed. The pam_krb5 package contains sample configuration files that allow services like login and gdm to authenticate users as well as obtain initial credentials using their passwords. If access to network servers is always performed using kerberized services or services that use GSS-API, such as IMAP, the network can be considered reasonably safe. Note Administrators should be careful to not allow users to authenticate to most network services using Kerberos passwords. Many protocols used by these services do not encrypt the password before sending it over the network, destroying the benefits of the Kerberos system. For example, users should not be allowed to authenticate using their Kerberos passwords over Telnet.

Commands:
Part II. Securing Data in Red Hat JBoss Data Grid In Red Hat JBoss Data Grid, data security can be implemented in the following ways: Role-based Access Control JBoss Data Grid features role-based access control for operations on designated secured caches. Roles can be assigned to users who access your application, with roles mapped to permissions for cache and cache-manager operations. Only authenticated users are able to perform the operations that are authorized for their role. In Library mode, data is secured via role-based access control for CacheManagers and Caches, with authentication delegated to the container or application. In Remote Client-Server mode, JBoss Data Grid is secured by passing identity tokens from the Hot Rod client to the server, and role-based access control of Caches and CacheManagers. Node Authentication and Authorization Node-level security requires new nodes or merging partitions to authenticate before joining a cluster. Only authenticated nodes that are authorized to join the cluster are permitted to do so. This provides data protection by preventing authorized servers from storing your data. Encrypted Communications Within the Cluster JBoss Data Grid increases data security by supporting encrypted communications between the nodes in a cluster by using a user-specified cryptography algorithm, as supported by Java Cryptography Architecture (JCA). JBoss Data Grid also provides audit logging for operations, and the ability to encrypt communication between the Hot Rod Client and Server using Transport Layer Security (TLS/SSL). Report a bug

Commands:
22.16.11. Configuring the iburst Option To improve the time taken for initial synchronization, add the following option to the end of a server command: iburst When the server is unreachable, send a burst of eight packets instead of the usual one packet. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. For use with the server command to reduce the time taken for initial synchronization. As of Red Hat Enterprise Linux 6.5, this is now a default option in the configuration file.

Commands:
32.8.2. Registering and Then Mounting an NFS Share Register the system to a Red Hat Subscription Management server (in this example, a local Subscription Asset Manager server): Run a script named runme from an NFS share: NFS file locking is not supported while in kickstart mode, therefore -o nolock is required when mounting an NFS mount.

Commands:
%post --log=/root/ks-post.log /usr/sbin/subscription-manager register --username=admin@example.com --password=secret --serverurl=sam-server.example.com --org="Admin Group" --environment="Dev" %end
mkdir /mnt/temp mount -o nolock 10.10.0.2:/usr/new-machines /mnt/temp openvt -s -w -- /mnt/temp/runme umount /mnt/temp
Chapter 2. Checking services using IdM Healthcheck You can monitor services used by the Identity Management (IdM) server using the Healthcheck tool. For details, see Healthcheck in IdM . 2.1. Services Healthcheck test The Healthcheck tool includes a test to check if any IdM services is not running. This test is important because services which are not running can cause failures in other tests. Therefore, check that all services are running first. You can then check all other test results. To see all services tests, run ipa-healthcheck with the --list-sources option: You can find all services tested with Healthcheck under the ipahealthcheck.meta.services source: certmonger dirsrv gssproxy httpd ipa_custodia ipa_dnskeysyncd ipa_otpd kadmin krb5kdc named pki_tomcatd sssd Note Run these tests on all IdM servers when trying to discover issues. 2.2. Screening services using Healthcheck Follow this procedure to run a standalone manual test of services running on the Identity Management (IdM) server using the Healthcheck tool. The Healthcheck tool includes many tests, whose results can be shortened with: Excluding all successful test: --failures-only Including only services tests: --source=ipahealthcheck.meta.services Procedure To run Healthcheck with warnings, errors and critical issues regarding services, enter: A successful test displays empty brackets: If one of the services fails, the result can looks similarly to this example: Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.meta.services --failures-only
{ "source": "ipahealthcheck.meta.services", "check": "httpd", "result": "ERROR", "kw": { "status": false, "msg": "httpd: not running" } }
2.4.2. Monitoring Bandwidth Monitoring bandwidth is more difficult than the other resources described here. The reason for this is due to the fact that performance statistics tend to be device-based, while most of the places where bandwidth is important tend to be the buses that connect devices. In those instances where more than one device shares a common bus, you might see reasonable statistics for each device, but the aggregate load those devices place on the bus would be much greater. Another challenge to monitoring bandwidth is that there can be circumstances where statistics for the devices themselves may not be available. This is particularly true for system expansion buses and datapaths [5] . However, even though 100% accurate bandwidth-related statistics may not always be available, there is often enough information to make some level of analysis possible, particularly when related statistics are taken into account. Some of the more common bandwidth-related statistics are: Bytes received/sent Network interface statistics provide an indication of the bandwidth utilization of one of the more visible buses -- the network. Interface counts and rates These network-related statistics can give indications of excessive collisions, transmit and receive errors, and more. Through the use of these statistics (particularly if the statistics are available for more than one system on your network), it is possible to perform a modicum of network troubleshooting even before the more common network diagnostic tools are used. Transfers per Second Normally collected for block I/O devices, such as disk and high-performance tape drives, this statistic is a good way of determining whether a particular device's bandwidth limit is being reached. Due to their electromechanical nature, disk and tape drives can only perform so many I/O operations every second; their performance degrades rapidly as this limit is reached. [5] More information on buses, datapaths, and bandwidth is available in Chapter 3, Bandwidth and Processing Power .

Commands: