mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Creating the Docker configuration value In this procedure, you create the final value you need in your ~/install_values.txt file. Prerequisites: A Quay.io account Procedure: In your web browser, login to Quay.io. In the right side of the banner, select your username and select Account Settings from the dropdown menu. On your user settings page, under Docker CLI Password , select Generate Encrypted Password . In the popup window, enter your password to authenticate. , still in the popup window, select Docker Configuration > View [username]-auth.json . Copy the string, without the quotation marks, following "auth": . In your ~/install_values.txt file, label and create the Docker configuration value with the following format, using your username and auth token where appropriate: {"auths": {"quay.io/[username]": {"auth": "[auth token]","email": ""}}} Note If you plan to use a private repository on Quay to host the images that RHTAP builds, you must also register that private repository with Advanced Cluster Security, as described in this document .

Commands:
14.10.3. Getting the UUID of a Guest Virtual Machine To get the Universally Unique Identifier (UUID) for a guest virtual machine: An example of virsh domuuid output:

Commands:
virsh domuuid {domain-id or domain-name}
virsh domuuid r5b2-mySQL01 4a4c59a7-ee3f-c781-96e4-288f2862f011
Chapter 6. Summarizing cluster specifications 6.1. Summarizing cluster specifications through clusterversion You can obtain a summary of OpenShift Container Platform cluster specifications by querying the clusterversion resource. Prerequisites You have access to the cluster as a user with the cluster-admin role. You have installed the OpenShift CLI ( oc ). Procedure Query cluster version, availability, uptime, and general status: USD oc get clusterversion Obtain a detailed summary of cluster specifications, update availability, and update history: USD oc describe clusterversion

Commands:
oc get clusterversion
oc describe clusterversion
Chapter 1. Operators overview Operators are among the most important components of OpenShift Container Platform. Operators are the preferred method of packaging, deploying, and managing services on the control plane. They can also provide advantages to applications that users run. Operators integrate with Kubernetes APIs and CLI tools such as kubectl and oc commands. They provide the means of monitoring applications, performing health checks, managing over-the-air (OTA) updates, and ensuring that applications remain in your specified state. While both follow similar Operator concepts and goals, Operators in OpenShift Container Platform are managed by two different systems, depending on their purpose: Cluster Operators, which are managed by the Cluster Version Operator (CVO), are installed by default to perform cluster functions. Optional add-on Operators, which are managed by Operator Lifecycle Manager (OLM), can be made accessible for users to run in their applications. With Operators, you can create applications to monitor the running services in the cluster. Operators are designed specifically for your applications. Operators implement and automate the common Day 1 operations such as installation and configuration as well as Day 2 operations such as autoscaling up and down and creating backups. All these activities are in a piece of software running inside your cluster. 1.1. For developers As a developer, you can perform the following Operator tasks: Install Operator SDK CLI . Create Go-based Operators , Ansible-based Operators , Java-based Operators , and Helm-based Operators . Use Operator SDK to build, test, and deploy an Operator . Install and subscribe an Operator to your namespace . Create an application from an installed Operator through the web console . Additional resources Machine deletion lifecycle hook examples for Operator developers 1.2. For administrators As a cluster administrator, you can perform the following Operator tasks: Manage custom catalogs . Allow non-cluster administrators to install Operators . Install an Operator from OperatorHub . View Operator status . Manage Operator conditions . Upgrade installed Operators . Delete installed Operators . Configure proxy support . Use Operator Lifecycle Manager on restricted networks . To know all about the cluster Operators that Red Hat provides, see Cluster Operators reference . 1.3. steps To understand more about Operators, see What are Operators?

Commands:
Chapter 7. Mirroring data for hybrid and Multicloud buckets You can use the simplified process of the Multicloud Object Gateway (MCG) to span data across cloud providers and clusters. Before you create a bucket class that reflects the data management policy and mirroring, you must add a backing storage that can be used by the MCG. For information, see Chapter 4, Chapter 3, Adding storage resources for hybrid or Multicloud . You can set up mirroring data by using the OpenShift UI, YAML or MCG command-line interface. See the following sections: Section 7.1, "Creating bucket classes to mirror data using the MCG command-line-interface" Section 7.2, "Creating bucket classes to mirror data using a YAML" 7.1. Creating bucket classes to mirror data using the MCG command-line-interface Prerequisites Ensure to download Multicloud Object Gateway (MCG) command-line interface. Procedure From the Multicloud Object Gateway (MCG) command-line interface, run the following command to create a bucket class with a mirroring policy: Set the newly created bucket class to a new bucket claim to generate a new bucket that will be mirrored between two locations: 7.2. Creating bucket classes to mirror data using a YAML Apply the following YAML. This YAML is a hybrid example that mirrors data between local Ceph storage and AWS: Add the following lines to your standard Object Bucket Claim (OBC): For more information about OBCs, see Chapter 11, Object Bucket Claim .

Commands:
noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
noobaa obc create mirrored-bucket --bucketclass=mirror-to-aws
apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: labels: app: noobaa name: <bucket-class-name> namespace: openshift-storage spec: placementPolicy: tiers: - backingStores: - <backing-store-1> - <backing-store-2> placement: Mirror
additionalConfig: bucketclass: mirror-to-aws
D.2. Enforcing Resource Timeouts There is no timeout for starting, stopping, or failing over resources. Some resources take an indeterminately long amount of time to start or stop. Unfortunately, a failure to stop (including a timeout) renders the service inoperable (failed state). You can, if desired, turn on timeout enforcement on each resource in a service individually by adding __enforce_timeouts="1" to the reference in the cluster.conf file. The following example shows a cluster service that has been configured with the __enforce_timeouts attribute set for the netfs resource. With this attribute set, then if it takes more than 30 seconds to unmount the NFS file system during a recovery process the operation will time out, causing the service to enter the failed state.

Commands:
</screen> <rm> <failoverdomains/> <resources> <netfs export="/nfstest" force_unmount="1" fstype="nfs" host="10.65.48.65" mountpoint="/data/nfstest" name="nfstest_data" options="rw,sync,soft"/> </resources> <service autostart="1" exclusive="0" name="nfs_client_test" recovery="relocate"> <netfs ref="nfstest_data" __enforce_timeouts="1"/> </service> </rm>
Chapter 8. The Basics of Managing the IdM Server and Services All of the access to Identity Management, both through the web UI and through the command line, is done by a user authenticating to the IdM domain. This chapter covers the basics of setting up browsers to handle Kerberos authentication, logging into Identity Management, and troubleshooting some common connection issues. 8.1. Starting and Stopping the IdM Domain When an IdM server is installed, there are a number of different services which can be installed and configured with it in any combination, including (but not limited to) a Directory Server, a certificate authority, a web server, DNS, NTP, certmonger, and Kerberos. All of these serveris work together in concert. Because there are dependencies between the services, the order in which services are started and stopped is critical. When changes are made to a single service (such as the LDAP directory or the web server), then that individual service can be started and stopped using the service command. However, when multiple domain services need to be restarted (or the entire IdM server), then use the ipactl command, which always starts and stops services in the appropriate order. Which services are configured for a specific IdM server are defined in the 389 Directory Server configuration, based on the hostname of the IdM server. [1] The 389 Directory Server service is always the first service started and the last service stopped. The rest of the run order depends on the configured services. The ipactl command can start, stop, and restart services. The chkconfig command sets what services to start automatically when the system restarts. The ipactl command can be used to start the domain services in the proper order, without having to configure each one individually in the chkconfig run order. [1] The hostname used in the directory lookup can be controlled in the /etc/ipa/default.conf configuration file.

Commands:
ipactl start | stop | restart
chkconfig ipactl on
Appendix A. Using your subscription AMQ is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. A.1. Accessing your account Procedure Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. A.2. Activating a subscription Procedure Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. A.3. Downloading release files To access .zip, .tar.gz, and other release files, use the customer portal to find the relevant files for download. If you are using RPM packages or the Red Hat Maven repository, this step is not required. Procedure Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ product. The Software Downloads page opens. Click the Download link for your component. A.4. Registering your system for packages To install RPM packages for this product on Red Hat Enterprise Linux, your system must be registered. If you are using downloaded release files, this step is not required. Procedure Go to access.redhat.com . Navigate to Registration Assistant . Select your OS version and continue to the page. Use the listed command in your system terminal to complete the registration. For more information about registering your system, see one of the following resources: Red Hat Enterprise Linux 7 - Registering the system and managing subscriptions Red Hat Enterprise Linux 8 - Registering the system and managing subscriptions

Commands:
2.7.6. Subnet Extrusion Using Libreswan IPsec is often deployed in a hub-and-spoke architecture. Each leaf node has an IP range that is part of a larger range. Leaves communicate with each other via the hub. This is called subnet extrusion . In the example below, we configure the head office with 10.0.0.0/8 and two branches that use a smaller /24 subnet. At the head office: At the " branch1 " office, we use the same connection. Additionally, we use a pass-through connection to exclude our local LAN traffic from being sent through the tunnel:

Commands:
conn branch1 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=5.6.7.8 rightid=@branch1 rightsubnet=10.0.1.0/24 rightrsasigkey=0sAXXXX[...] # auto=start authby=rsasig conn branch2 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=10.11.12.13 rightid=@branch2 rightsubnet=10.0.2.0/24 rightrsasigkey=0sAYYYY[...] # auto=start authby=rsasig
conn branch1 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=10.11.12.13 rightid=@branch2 rightsubnet=10.0.1.0/24 rightrsasigkey=0sAYYYY[...] # auto=start authby=rsasig conn passthrough left=1.2.3.4 right=0.0.0.0 leftsubnet=10.0.1.0/24 rightsubnet=10.0.1.0/24 authby=never type=passthrough auto=route
Part II. Interacting with processes and tasks As a knowledge worker, you use Business Central in Red Hat Process Automation Manager to run processes and tasks of the business process application developed by citizen developers. A business process is a series of steps that are executed as defined in the process flow. To effectively interact with processes and tasks, you must have a clear understanding of the business process and be able to determine the current step of a process or task. You can start and stop tasks; search and filter tasks and process instances; delegate, claim, and release tasks; set a due date and priority of tasks; view and add comments to tasks; and view the task history log. Prerequisites Red Hat Process Automation Manager is installed. For installation options, see Planning a Red Hat Process Automation Manager installation .

Commands:
36.6.5. IBM eServer pSeries Systems IBM eServer pSeries systems use YABOOT as the boot loader, which uses /etc/aboot.conf as the configuration file. Confirm that the file contains an image section with the same version as the kernel package just installed: Notice that the default is not set to the new kernel. The kernel in the first image is booted by default. To change the default kernel to boot either move its image stanza so that it is the first one listed or add the directive default and set it to the label of the image stanza that contains the new kernel. Begin testing the new kernel by rebooting the computer and watching the messages to ensure that the hardware is detected properly.

Commands:
boot=/dev/sda1 init-message=Welcome to Red Hat Enterprise Linux! Hit <TAB> for boot options partition=2 timeout=30 install=/usr/lib/yaboot/yaboot delay=10 nonvram image=/vmlinux--2.6.9-5.EL label=old read-only initrd=/initrd--2.6.9-5.EL.img append="root=LABEL=/" image=/vmlinux-2.6.9-5.EL label=linux read-only initrd=/initrd-2.6.9-5.EL.img append="root=LABEL=/"
Preface Red Hat OpenShift Data Foundation 4.9 supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) AWS clusters in connected or disconnected environments along with out-of-the-box support for proxy environments. Note Only internal OpenShift Data Foundation clusters are supported on AWS. See Planning your deployment and Preparing to deploy OpenShift Data Foundation for more information about deployment requirements. To deploy OpenShift Data Foundation, start with the requirements in Preparing to deploy OpenShift Data Foundation chapter and then follow the deployment process for your environment based on your requirement: Deploy using dynamic storage devices Deploy standalone Multicloud Object Gateway component

Commands:
Chapter 3. Setting persistent kernel tuning parameters When you have decided on a tuning configuration that works for your system, you can make the changes persistent across reboots. By default, edited kernel tuning parameters only remain in effect until the system reboots or the parameters are explicitly changed. This is effective for establishing the initial tuning configuration. It also provides a safety mechanism. If the edited parameters cause the machine to behave erratically, rebooting the machine returns the parameters to the configuration. 3.1. Making persistent kernel tuning parameter changes You can make persistent changes to kernel tuning parameters by adding the parameter to the /etc/sysctl.conf file. Note This procedure does not change any of the kernel tuning parameters in the current session. The changes entered into /etc/sysctl.conf only affect future sessions. Prerequisites You have root permissions on the system. Procedure Open /etc/sysctl.conf in a text editor. Insert the new entry into the file with the parameter's value. Modify the parameter name by removing the /proc/sys/ path, changing the remaining slash ( / ) to a period ( . ), and including the parameter's value. For example, to make the command echo 0 > /proc/sys/kernel/hung_task_panic persistent, enter the following into /etc/sysctl.conf : Save and close the file. Reboot the system for changes to take effect. Verification To verify the configuration:

Commands:
Enable gettimeofday(2) kernel.hung_task_panic = 0
cat /proc/sys/kernel/hung_task_panic 0
Chapter 1. Monitoring APIs 1.1. Alertmanager [monitoring.coreos.com/v1] Description Alertmanager describes an Alertmanager cluster. Type object 1.2. AlertmanagerConfig [monitoring.coreos.com/v1beta1] Description AlertmanagerConfig configures the Prometheus Alertmanager, specifying how alerts should be grouped, inhibited and notified to external systems. Type object 1.3. AlertRelabelConfig [monitoring.openshift.io/v1] Description AlertRelabelConfig defines a set of relabel configs for alerts. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.4. AlertingRule [monitoring.openshift.io/v1] Description AlertingRule represents a set of user-defined Prometheus rule groups containing alerting rules. This resource is the supported method for cluster admins to create alerts based on metrics recorded by the platform monitoring stack in OpenShift, i.e. the Prometheus instance deployed to the openshift-monitoring namespace. You might use this to create custom alerting rules not shipped with OpenShift based on metrics from components such as the node_exporter, which provides machine-level metrics such as CPU usage, or kube-state-metrics, which provides metrics on Kubernetes usage. The API is mostly compatible with the upstream PrometheusRule type from the prometheus-operator. The primary difference being that recording rules are not allowed here - only alerting rules. For each AlertingRule resource created, a corresponding PrometheusRule will be created in the openshift-monitoring namespace. OpenShift requires admins to use the AlertingRule resource rather than the upstream type in order to allow better OpenShift specific defaulting and validation, while not modifying the upstream APIs directly. You can find upstream API documentation for PrometheusRule resources here: https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.5. PodMonitor [monitoring.coreos.com/v1] Description PodMonitor defines monitoring for a set of pods. Type object 1.6. Probe [monitoring.coreos.com/v1] Description Probe defines monitoring for a set of static targets or ingresses. Type object 1.7. Prometheus [monitoring.coreos.com/v1] Description Prometheus defines a Prometheus deployment. Type object 1.8. PrometheusRule [monitoring.coreos.com/v1] Description PrometheusRule defines recording and alerting rules for a Prometheus instance Type object 1.9. ServiceMonitor [monitoring.coreos.com/v1] Description ServiceMonitor defines monitoring for a set of services. Type object 1.10. ThanosRuler [monitoring.coreos.com/v1] Description ThanosRuler defines a ThanosRuler deployment. Type object 1.11. NodeMetrics [metrics.k8s.io/v1beta1] Description NodeMetrics sets resource usage metrics of a node. Type object 1.12. PodMetrics [metrics.k8s.io/v1beta1] Description PodMetrics sets resource usage metrics of a pod. Type object

Commands:
Chapter 2. Accessing hosts Learn how to create a bastion host to access OpenShift Container Platform instances and access the control plane nodes with secure shell (SSH) access. 2.1. Accessing hosts on Amazon Web Services in an installer-provisioned infrastructure cluster The OpenShift Container Platform installer does not create any public IP addresses for any of the Amazon Elastic Compute Cloud (Amazon EC2) instances that it provisions for your OpenShift Container Platform cluster. To be able to SSH to your OpenShift Container Platform hosts, you must follow this procedure. Procedure Create a security group that allows SSH access into the virtual private cloud (VPC) created by the openshift-install command. Create an Amazon EC2 instance on one of the public subnets the installer created. Associate a public IP address with the Amazon EC2 instance that you created. Unlike with the OpenShift Container Platform installation, you should associate the Amazon EC2 instance you created with an SSH keypair. It does not matter what operating system you choose for this instance, as it will simply serve as an SSH bastion to bridge the internet into your OpenShift Container Platform cluster's VPC. The Amazon Machine Image (AMI) you use does matter. With Red Hat Enterprise Linux CoreOS (RHCOS), for example, you can provide keys via Ignition, like the installer does. After you provisioned your Amazon EC2 instance and can SSH into it, you must add the SSH key that you associated with your OpenShift Container Platform installation. This key can be different from the key for the bastion instance, but does not have to be. Note Direct SSH access is only recommended for disaster recovery. When the Kubernetes API is responsive, run privileged pods instead. Run oc get nodes , inspect the output, and choose one of the nodes that is a master. The hostname looks similar to ip-10-0-1-163.ec2.internal . From the bastion SSH host you manually deployed into Amazon EC2, SSH into that control plane host. Ensure that you use the same SSH key you specified during the installation: USD ssh -i <ssh-key-path> core@<master-hostname>

Commands:
ssh -i <ssh-key-path> core@<master-hostname>
Chapter 6. Troubleshooting 6.1. Troubleshooting Pod Restarts Pods can restart for a number of reasons, but a common cause of JBoss EAP pod restarts might include OpenShift resource constraints, especially out-of-memory issues. See the OpenShift documentation for more information on OpenShift pod eviction . By default, JBoss EAP for OpenShift templates are configured to automatically restart affected containers when they encounter situations like out-of-memory issues. The following steps can help you diagnose and troubleshoot out-of-memory and other pod restart issues. Get the name of the pod that has been having trouble. You can see pod names, as well as the number times each pod has restarted with the following command. To diagnose why a pod has restarted, you can examine the JBoss EAP logs of the pod, or the OpenShift events. To see the JBoss EAP logs of the pod, use the following command. To see the OpenShift events, use the following command. If a pod has restarted because of a resource issue, you can attempt to modify your OpenShift pod configuration to increase its resource requests and limits . See the OpenShift documentation for more information on configuring pod compute resources . 6.2. Troubleshooting Using the JBoss EAP Management CLI The JBoss EAP management CLI, EAP_HOME /bin/jboss-cli.sh , is accessible from within a container for troubleshooting purposes. Important It is not recommended to make configuration changes in a running pod using the JBoss EAP management CLI. Any configuration changes made using the management CLI in a running container will be lost when the container restarts. To make configuration changes to JBoss EAP for OpenShift, see Configuring the JBoss EAP for OpenShift Image for Your Java Application . First open a remote shell session to the running pod. Run the following command from the remote shell session to launch the JBoss EAP management CLI:

Commands:
oc get pods
logs --previous POD_NAME
oc get events
oc rsh POD_NAME
/opt/eap/bin/jboss-cli.sh