mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Installing the high availability and RHOSP packages and agents Install the packages required for configuring a Red Hat High Availability cluster on Red Hat OpenStack Platform (RHOSP). You must install the packages on each of the nodes you will use as cluster members. Prerequisites A server group for the RHOSP instances to use as HA cluster nodes, configured as described in RHOSP server group configuration for HA instances An RHOSP instance for each HA cluster node The instances are members of a server group The instances are configured as nodes running RHEL 8.7 or later Procedure Enable the RHEL HA repositories and the RHOSP tools channel. Install the Red Hat High Availability Add-On software packages and the packages that are required for the RHOSP cluster resource agents and the RHOSP fence agents. Installing the pcs and pacemaker packages on each node creates the user hacluster , which is the pcs administration account. Create a password for user hacluster on all cluster nodes. Using the same password for all nodes simplifies cluster administration. If firewalld.service is installed, add the high-availability service to the RHEL firewall. Start the pcs service and enable it to start on boot. Verify that the pcs service is running. Edit the /etc/hosts file and add RHEL host names and internal IP addresses. For information about /etc/hosts , see the Red Hat Knowledgebase solution How should the /etc/hosts file be set up on RHEL cluster nodes? . Additional resources For further information about configuring and managing Red Hat high availability clusters, see Configuring and managing high availability clusters .

Commands:
subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms subscription-manager repos --enable=openstack-16-tools-for-rhel-8-x86_64-rpms
yum install pcs pacemaker python3-openstackclient python3-novaclient fence-agents-openstack
passwd hacluster
firewall-cmd --permanent --add-service=high-availability firewall-cmd --add-service=high-availability
systemctl start pcsd.service systemctl enable pcsd.service
systemctl status pcsd.service pcsd.service - PCS GUI and remote configuration interface Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2018-03-01 14:53:28 UTC; 28min ago Docs: man:pcsd(8) man:pcs(8) Main PID: 5437 (pcsd) CGroup: /system.slice/pcsd.service └─5437 /usr/bin/ruby /usr/lib/pcsd/pcsd > /dev/null & Mar 01 14:53:27 ip-10-0-0-48.ec2.internal systemd[1]: Starting PCS GUI and remote configuration interface... Mar 01 14:53:28 ip-10-0-0-48.ec2.internal systemd[1]: Started PCS GUI and remote configuration interface.
Technology preview The Streams for Apache Kafka Proxy is a technology preview. Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete; therefore, Red Hat does not recommend implementing any Technology Preview features in production environments. This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about the support scope, see Technology Preview Features Support Scope .

Commands:
Chapter 14. Volume cloning A clone is a duplicate of an existing storage volume that is used as any standard volume. You create a clone of a volume to make a point in time copy of the data. A persistent volume claim (PVC) cannot be cloned with a different size. You can create up to 512 clones per PVC for both CephFS and RADOS Block Device (RBD). 14.1. Creating a clone Prerequisites Source PVC must be in Bound state and must not be in use. Note Do not create a clone of a PVC if a Pod is using it. Doing so might cause data corruption because the PVC is not quiesced (paused). Procedure Click Storage Persistent Volume Claims from the OpenShift Web Console. To create a clone, do one of the following: Beside the desired PVC, click Action menu (...) Clone PVC . Click on the PVC that you want to clone and click Actions Clone PVC . Enter a Name for the clone. Select the access mode of your choice. Important The ReadOnlyMany (ROX) access mode is a Developer Preview feature and is subject to Developer Preview support limitations. Developer Preview releases are not intended to be run in production environments and are not supported through the Red Hat Customer Portal case management system. If you need assistance with ReadOnlyMany feature, reach out to the ocs-devpreview@redhat.com mailing list and a member of the Red Hat Development Team will assist you as quickly as possible based on availability and work schedules. See Creating a clone or restoring a snapshot with the new readonly access mode to use the ROX access mode. Enter the required size of the clone. Select the storage class in which you want to create the clone. The storage class can be any RBD storage class and it need not necessarily be the same as the parent PVC. Click Clone . You are redirected to the new PVC details page. Wait for the cloned PVC status to become Bound . The cloned PVC is now available to be consumed by the pods. This cloned PVC is independent of its dataSource PVC.

Commands:
5.101. gvfs 5.101.1. RHBA-2012:1124 - gvfs bug fix and enhancement update Updated gvfs packages that fix multiple bugs are now available for Red Hat Enterprise Linux 6. GVFS is the GNOME desktop's virtual file system layer, which allows users to easily access local and remote data, including via the FTP, SFTP, WebDAV, CIFS and SMB protocols, among others. GVFS integrates with the GIO (GNOME I/O) abstraction layer. Bug Fixes BZ# 599055 Previously, rules for ignoring mounts were too restrictive. If the user clicked on an encrypted volume in the Nautilus' sidebar, an error message was displayed and the volume could not be accessed. The underlying source code now contains additional checks so that encrypted volumes have proper mounts associated (if available), and the file system can be browsed as expected. BZ# 669526 Due to a bug in the kernel, a freshly formatted Blu-ray Disk Rewritable (BD-RE) medium contains a single track with invalid data that covers the whole medium. This empty track was previously incorrectly detected, causing the drive to be unusable for certain applications, such as Brasero. This update adds a workaround to detect the empty track, so that freshly formatted BD-RE media are properly recognized as blank. BZ# 682799 , BZ# 746977 , BZ# 746978 , BZ# 749369 , BZ# 749371 , BZ# 749372 The code of the gvfs-info, gvfs-open, gvfs-cat, gvfs-ls and gvfs-mount utilities contained hard-coded exit codes. This caused the utilities to always return zero on exit. The exit codes have been revised so that the mentioned gvfs utilities now return proper exit codes. BZ# 746905 When running gvfs-set-attribute with an invalid command-line argument specified, the utility terminated unexpectedly with a segmentation fault. The underlying source code has been modified so that the utility now prints a proper error message when an invalid argument is specified. BZ# 809708 Due to missing object cleanup calls, the gvfsd daemon could use excessive amount of memory, which caused the system to become unresponsive. Proper object cleanup calls have been added with this update, which ensures that the memory consumption is constant and the system does not hang in this scenario. All users of gvfs are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 4. Control Group Application Examples This chapter provides application examples that take advantage of the cgroup functionality. 4.1. Prioritizing Database I/O Running each instance of a database server inside its own dedicated virtual guest allows you to allocate resources per database based on their priority. Consider the following example: a system is running two database servers inside two KVM guests. One of the databases is a high priority database and the other one a low priority database. When both database servers are run simultaneously, the I/O throughput is decreased to accommodate requests from both databases equally; Figure 4.1, "I/O throughput without resource allocation" indicates this scenario - once the low priority database is started (around time 45), I/O throughput is the same for both database servers. Figure 4.1. I/O throughput without resource allocation To prioritize the high priority database server, it can be assigned to a cgroup with a high number of reserved I/O operations, whereas the low priority database server can be assigned to a cgroup with a low number of reserved I/O operations. To achieve this, follow the steps in Procedure 4.1, "I/O Throughput Prioritization" , all of which are performed on the host system. Procedure 4.1. I/O Throughput Prioritization Make sure resource accounting is on for both services: Set a ratio of 10:1 for the high and low priority services. Processes running in those service units will use only the resources made available to them Figure 4.2, "I/O throughput with resource allocation" illustrates the outcome of limiting the low priority database and prioritizing the high priority database. As soon as the database servers are moved to their appropriate cgroups (around time 75), I/O throughput is divided between both servers with the ratio of 10:1. Figure 4.2. I/O throughput with resource allocation Alternatively, block device I/O throttling can be used for the low priority database to limit its number of read and write operations. For more information, see the description of the blkio controller in Controller-Specific Kernel Documentation .

Commands:
~]# systemctl set-property db1.service BlockIOAccounting = true ~]# systemctl set-property db2.service BlockIOAccounting = true
~]# systemctl set-property db1.service BlockIOWeight = 1000 ~]# systemctl set-property db2.service BlockIOWeight = 100
7.213. rgmanager 7.213.1. RHBA-2013:0409 - rgmanager bug fix update Updated rgmanager packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The rgmanager packages contain the Red Hat Resource Group Manager, which allows to create and manage high-availability server applications in the event of system downtime. Bug Fixes BZ# 825375 Due to an unlocked access to internal DBus data structures from different rgmanager threads, rgmanager could terminate unexpectedly inside dbus library functions when running rgmanager without the "-q" flag (set as default). The underlying source code has been modified and rgmanager no longer fails in this situation. BZ#831658 Previously, rgmanager preferred two nodes in a three-nodes cluster, which caused the third node being unused. The configuration has been changed and rgmanager now uses all nodes in the cluster as expected. BZ# 833347 Previously, the cpglockd init script was not included in the chkconfig configuration file. This updated adds cpglockd in this file. BZ#853251 Resource Group Manager fails to stop a resource if it is located on an unmounted file system. As a result of this failure, rgmanager treated the resource as missing and marked the appropriate service as failed, which prevented the cluster from recovering the service. This update allows rgmanager to ignore this error if a resource has not been previously started with a service. The service can now be properly started on a different host. BZ#861157 When rgmanager received a remote start message for a particular service while already in the process of starting that service locally, a deadlock could occur. This sometimes happened during the recovery of a service that had failed its start operation. This bug has been fixed and rgmanager works as expected. BZ#879031 When a service is configured with a recoverable resource, such as nfsclient, a failure of that client correctly triggers the recovery function. However, even if recovery operation was successful, rgmanager still stopped and recovered the service. The underlying source code has been modified and rgmanager no longer stops successfully recovered clients. All users of rgmanager are advised to upgrade to these updated packages, which fix these bugs.

Commands:
3.6. Tickless Kernel Previously, the Linux kernel periodically interrupted each CPU on a system at a predetermined frequency - 100 Hz, 250 Hz, or 1000 Hz, depending on the platform. The kernel queried the CPU about the processes that it was executing, and used the results for process accounting and load balancing. Known as the timer tick , the kernel performed this interrupt regardless of the power state of the CPU. Therefore, even an idle CPU was responding to up to 1000 of these requests every second. On systems that implemented power saving measures for idle CPUs, the timer tick prevented the CPU from remaining idle long enough for the system to benefit from these power savings. The kernel in Red Hat Enterprise Linux 6 runs tickless : that is, it replaces the old periodic timer interrupts with on-demand interrupts. Therefore, idle CPUs are allowed to remain idle until a new task is queued for processing, and CPUs that have entered lower power states can remain in these states longer.

Commands:
Chapter 1. Introduction to OpenShift Data Foundation Disaster Recovery Disaster recovery (DR) is the ability to recover and continue business critical applications from natural or human created disasters. It is a component of the overall business continuance strategy of any major organization as designed to preserve the continuity of business operations during major adverse events. The OpenShift Data Foundation DR capability enables DR across multiple Red Hat OpenShift Container Platform clusters, and is categorized as follows: Metro-DR Metro-DR ensures business continuity during the unavailability of a data center with no data loss. In the public cloud these would be similar to protecting from an Availability Zone failure. Regional-DR Regional-DR ensures business continuity during the unavailability of a geographical region, accepting some loss of data in a predictable amount. In the public cloud this would be similar to protecting from a region failure. Disaster Recovery with stretch cluster Stretch cluster solution ensures business continuity with no-data loss disaster recovery protection with OpenShift Data Foundation based synchronous replication in a single OpenShift cluster, stretched across two data centers with low latency and one arbiter node. Zone failure in Metro-DR and region failure in Regional-DR is usually expressed using the terms, Recovery Point Objective (RPO) and Recovery Time Objective (RTO) . RPO is a measure of how frequently you take backups or snapshots of persistent data. In practice, the RPO indicates the amount of data that will be lost or need to be reentered after an outage. RTO is the amount of downtime a business can tolerate. The RTO answers the question, "How long can it take for our system to recover after we are notified of a business disruption?" The intent of this guide is to detail the Disaster Recovery steps and commands necessary to be able to failover an application from one OpenShift Container Platform cluster to another and then relocate the same application to the original primary cluster.

Commands:
7.126. mercurial 7.126.1. RHBA-2015:1436 - mercurial bug fix update Updated mercurial packages that fix several bugs are now available for Red Hat Enterprise Linux 6. Mercurial is a lightweight source control management system designed for managing large distributed projects. Bug Fixes BZ# 784079 Previously, the "hg view" command failed with the "Permission denied" error message. This update adds the required execute permission to the hgk utility. As a result, running "hg view" works as expected. BZ# 928301 Running an SSL-encrypted "hg serve" command could previously cause the server to rise an exception and tracebacks on every SSL connection attempt. As a consequence, "hg serve" failed in this situation even though it worked as expected without SSL. A patch has been applied to fix this bug. As a result, running SSL-encrypted "hg serve" works, and the command displays the expected output. BZ# 1006457 Prior to this update, running the "hg copy -A" command did not add broken symbolic links to a repository. The underlying source code has been modified to use the os.patch.lexists() method. As a result, "hg copy -A" adds the broken symbolic links as expected. Users of mercurial are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 5. Using custom Red Hat build of Keycloak images 5.1. Red Hat build of Keycloak custom image with the Operator With the Keycloak Custom Resource (CR), you can specify a custom container image for the Red Hat build of Keycloak server. Note To ensure full compatibility of Operator and Operand, make sure that the version of Red Hat build of Keycloak release used in the custom image is aligned with the version of the operator. 5.1.1. Best practice When using the default Red Hat build of Keycloak image, the server will perform a costly re-augmentation every time a Pod starts. To avoid this delay, you can provide a custom image with the augmentation built-in from the build time of the image. With a custom image, you can also specify the Keycloak build-time configurations and extensions during the build of the container. For instructions on how to build such an image, see Running Red Hat build of Keycloak in a container . 5.1.2. Providing a custom Red Hat build of Keycloak image To provide a custom image, you define the image field in the Keycloak CR as shown in this example: apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: instances: 1 image: quay.io/my-company/my-keycloak:latest http: tlsSecret: example-tls-secret hostname: hostname: test.keycloak.org Note With custom images, every build time option passed either through a dedicated field or the additionalOptions is ignored. 5.1.3. Non-optimized custom image While it is considered a best practice use a pre-augmented image, if you want to use a non-optimized custom image or build time properties with an augmented image that is still possible. You just need set the startOptimzed field to false as shown in this example: apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: instances: 1 image: quay.io/my-company/my-keycloak:latest startOptimized: false http: tlsSecret: example-tls-secret hostname: hostname: test.keycloak.org Keep in mind this will incur the re-augmentation cost on every start.

Commands:
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: instances: 1 image: quay.io/my-company/my-keycloak:latest http: tlsSecret: example-tls-secret hostname: hostname: test.keycloak.org
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: instances: 1 image: quay.io/my-company/my-keycloak:latest startOptimized: false http: tlsSecret: example-tls-secret hostname: hostname: test.keycloak.org
7.197. python-rhsm 7.197.1. RHBA-2013:0371 - python-rhsm bug fix and enhancement update Updated python-rhsm packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The python-rhsm packages contain a library for communicating with the representational state transfer (REST) interface of Red Hat's subscription and content service. This interface is used by the Subscription Management tools for management of system entitlements, certificates, and access to content. Note The python-rhsm packages have been upgraded to upstream version 1.1.7, which provides a number of bug fixes and enhancements over the version. (BZ# 860306 ) Enhancement BZ# 790481 This enhancement allows the opportunity to add the value of the subscription-manager version to the X-HTTP header field. All users of python-rhsm are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 10. Reviewing monitoring dashboards OpenShift Container Platform 4.10 provides a comprehensive set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads. Use the Administrator perspective to access dashboards for the core OpenShift Container Platform components, including the following items: API performance etcd Kubernetes compute resources Kubernetes network resources Prometheus USE method dashboards relating to cluster and node performance Figure 10.1. Example dashboard in the Administrator perspective Use the Developer perspective to access Kubernetes compute resources dashboards that provide the following application metrics for a selected project: CPU usage Memory usage Bandwidth information Packet rate information Figure 10.2. Example dashboard in the Developer perspective Note In the Developer perspective, you can view dashboards for only one project at a time. 10.1. Reviewing monitoring dashboards as a cluster administrator In the Administrator perspective, you can view dashboards relating to core OpenShift Container Platform cluster components. Prerequisites You have access to the cluster as a user with the cluster-admin cluster role. Procedure In the Administrator perspective in the OpenShift Container Platform web console, navigate to Observe Dashboards . Choose a dashboard in the Dashboard list. Some dashboards, such as etcd and Prometheus dashboards, produce additional sub-menus when selected. Optional: Select a time range for the graphs in the Time Range list. Select a pre-defined time period. Set a custom time range by selecting Custom time range in the Time Range list. Input or select the From and To dates and times. Click Save to save the custom time range. Optional: Select a Refresh Interval . Hover over each of the graphs within a dashboard to display detailed information about specific items. 10.2. Reviewing monitoring dashboards as a developer Use the Developer perspective to view Kubernetes compute resources dashboards of a selected project. Prerequisites You have access to the cluster as a developer or as a user. You have view permissions for the project that you are viewing the dashboard for. Procedure In the Developer perspective in the OpenShift Container Platform web console, navigate to Observe Dashboard . Select a project from the Project: drop-down list. Select a dashboard from the Dashboard drop-down list to see the filtered metrics. Note All dashboards produce additional sub-menus when selected, except Kubernetes / Compute Resources / Namespace (Pods) . Optional: Select a time range for the graphs in the Time Range list. Select a pre-defined time period. Set a custom time range by selecting Custom time range in the Time Range list. Input or select the From and To dates and times. Click Save to save the custom time range. Optional: Select a Refresh Interval . Hover over each of the graphs within a dashboard to display detailed information about specific items. Additional resources Monitoring project and application metrics using the Developer perspective 10.3. steps Accessing third-party monitoring UIs and APIs

Commands:
Preface The Red Hat Enterprise Linux 6.3 Technical Notes list and document the changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications between minor release Red Hat Enterprise Linux 6.2 and minor release Red Hat Enterprise Linux 6.3. For system administrators and others planning Red Hat Enterprise Linux 6.3 upgrades and deployments, the Technical Notes provide a single, organized record of the bugs fixed in, features added to, and Technology Previews included with this new release of Red Hat Enterprise Linux. For auditors and compliance officers, the Red Hat Enterprise Linux 6.3 Technical Notes provide a single, organized source for change tracking and compliance testing. For every user, the Red Hat Enterprise Linux 6.3 Technical Notes provide details of what has changed in this new release. Note The Package Manifest is available as a separate document.

Commands: