mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Pulling images from a container repository Pull images from the automation hub container registry to make a copy to your local machine. Automation hub provides the podman pull command for each latest image in the container repository. You can copy and paste this command into your terminal, or use podman pull to copy an image based on an image tag. 5.1. Prerequisites You must have permission to view and pull from a private container repository. 5.2. Pulling an image You can pull images from the automation hub container registry to make a copy to your local machine. Automation hub provides the podman pull command for each latest image in the container repository. Note If you need to pull container images from a password or token-protected registry, you must create a credential in automation controller before pulling the image. Procedure Navigate to Execution Environments . Select your container repository. In the Pull this image entry, click Copy to clipboard . Paste and run the command in your terminal. Verification Run podman images to view images on your local machine. 5.3. Syncing images from a container repository You can pull images from the automation hub container registry to sync an image to your local machine. Prerequisites You must have permission to view and pull from a private container repository. Procedure To sync an image from a remote container registry, you need to configure a remote registry. Navigate to Execution Environments Remote Registries . Add https://registry.redhat.io to the registry. Add any required credentials to authenticate. Note Some container registries are aggressive with rate limiting. It is advisable to set a rate limit under Advanced Options. Navigate to Execution Environments Execution Environments . Click Add execution environment in the page header. Select the registry you wish to pull from. The "name" field displays the name of the image that will show up as on your local registry. Note The "Upstream name" field is the name of the image on the remote server. For example if the upstream name is set to "alpine" and the "name" field to "local/alpine", the alpine image will be downloaded from the remote and renamed to local/alpine. It is advisable to set a list of tags to include or exclude. Syncing images with a large number of tags is time consuming and will use a lot of disk space. Additional resources See Red Hat Container Registry Authentication for a list of registries. 5.4. Additional resources See the What is Podman? documentation for options to use when pulling images.

Commands:
Chapter 1. Updating Satellite to the minor version You can update your Satellite Server and Capsule Server to a new minor release version, such as from 6.15.0 to 6.15.1, using the Satellite maintain tool. The minor releases are non-disruptive to your operating environment and often fast. Red Hat recommends performing updates regularly, because the minor releases patch security vulnerabilities and minor issues discovered after code is released.

Commands:
Chapter 6. Getting support for your clusters 6.1. OpenShift Container Platform support For help with your Red Hat OpenShift Container Platform clusters, contact Red Hat Support . From here, you can: Open a new support case. Also see Submitting a support case in the OpenShift Container Platform documentation for instructions. View your open support cases: https://access.redhat.com/support/cases/#/case/list Open a live chat with support engineers Call or email a Red Hat Support expert Additional resources See Getting support in the OpenShift Container Platform documentation for more information. 6.2. OpenShift Dedicated support For questions about your existing Red Hat OpenShift Dedicated clusters, contact Red Hat Support . From here, you can: Open a new support case: https://access.redhat.com/support/cases/#/case/ View open support cases: https://access.redhat.com/support/cases/#/case/list Open a live chat with support engineers Call or email a Red Hat Support expert See Support in the OpenShift Dedicated documentation for more information. 6.3. Red Hat OpenShift Service on AWS (ROSA) support For questions about your existing Red Hat OpenShift Service on AWS (ROSA) clusters, contact Red Hat Support . From here, you can: Open a new support case: https://access.redhat.com/support/cases/#/case/ View open support cases: https://access.redhat.com/support/cases/#/case/list Open a live chat with support engineers Call or email a Red Hat Support expert See Getting support for Red Hat OpenShift Service on AWS in the ROSA documentation for more information.

Commands:
Chapter 7. Streams for Apache Kafka Proxy overview Streams for Apache Kafka Proxy is an Apache Kafka protocol-aware ("Layer 7") proxy designed to enhance Kafka-based systems. Through its filter mechanism it allows additional behavior to be introduced into a Kafka-based system without requiring changes to either your applications or the Kafka cluster itself. Built-in filters are provided as part of the solution. Functioning as an intermediary, the Streams for Apache Kafka Proxy mediates communication between a Kafka cluster and its clients. It takes on the responsibility of receiving, filtering, and forwarding messages. An API provides a convenient means for implementing custom logic within the proxy. Important This feature is a technology preview and not intended for a production environment. For more information see the release notes .

Commands:
8.17. avahi 8.17.1. RHBA-2014:1535 - avahi bug fix update Updated avahi packages that fix several bugs are now available for Red Hat Enterprise Linux 6. Avahi is an implementation of the DNS Service Discovery and Multicast DNS specifications for Zero Configuration Networking. It facilitates service discovery on a local network. Avahi and Avahi-aware applications allow you to plug your computer into a network and, with no configuration, view other people to chat with, view printers to print to, and find shared files on other computers. Bug Fixes BZ# 768708 , BZ# 885849 Previously, when the ARCOUNT field in the DNS Response Header contained a non-zero value, avahi-daemon performed a check and logged errors about invalid DNS packets being received. Note that a non-zero value of ARCOUNT is an indication of additional data sections in the DNS packet, but avahi-daemon does not interpret them. As a consequence, avahi-daemon was not sufficiently interoperable with other mDNS/DNS-SD implementations, and the automatic service discovery thus did not provide the user with the expected results on some platforms. Additionally, avahi-daemon logged inaccurate information which cluttered log files. The redundant check has been removed, and the described situation no longer occurs. BZ# 1074028 Previously, various options such as maximum count of cached resource records or numerous options related to handling of connected clients to the avahi-daemon could not be configured. As a consequence, in large networks, the avahi-daemon could reach the upper bound of some internal limits. In addition, the avahi-daemon was exhibiting erroneous behavior, such as logging error messages and failing to discover some services in large networks. To fix this bug, support for configuring various internal limits has been introduced with the following newly added options: cache-entries-max, clients-max, objects-per-client-max, entries-per-entry-group-max. For details about these options, see the avahi-daemon.conf(5) manual page. Users of avahi are advised to upgrade to these updated packages, which fix these bugs. After installing the update, avahi-daemon will be restarted automatically.

Commands:
Chapter 10. Renaming an IdM server You cannot change the host name of an existing Identity Management (IdM) server. However, you can replace the server with a replica of a different name. Procedure Install a new replica that will replace the existing server, ensuring the replica has the required host name and IP address. For details, see Installing an IdM replica . Important If the server you are uninstalling is the certificate revocation list (CRL) publisher server, make another server the CRL publisher server before proceeding. For details on how this is done in the context of a migration procedure, see the following sections: Stopping CRL generation on a RHEL 8 IdM CA server Starting CRL generation on the new RHEL 9 IdM CA server Stop the existing IdM server instance. Uninstall the existing server as described in Uninstalling an IdM server .

Commands:
ipactl stop
16.4. Using the HMC vterm The HMC vterm is the console for any partitioned IBM System p. This is opened by right clicking on the partition on the HMC, and then selecting Open Terminal Window . Only a single vterm can be connected to the console at one time and there is no console access for partitioned system besides the vterm. This often is referred to as a 'virtual console', but is different from the virtual consoles in Section 16.3, "A Note About Linux Virtual Consoles" .

Commands:
2.26. RHEA-2011:0617 - new package: perl-Parse-RecDescent A new perl-Parse-RecDescent package is now available for Red Hat Enterprise Linux 6. The Parse::RecDescent module provides a mechanism for Perl scripts to generate top-down recursive-descent text parsers from grammar specifications similar to yacc. This enhancement update adds the perl-Parse-RecDescent package to Red Hat Enterprise Linux 6. (BZ# 643547 ) All users who require the Parse::RecDescent Perl module should install this new package.

Commands:
Chapter 21. Network File System (NFS) Network File System (NFS) is a way to share files between machines on a network as if the files were located on the client's local hard drive. Red Hat Enterprise Linux can be both an NFS server and an NFS client, which means that it can export file systems to other systems and mount file systems exported from other machines. 21.1. Why Use NFS? NFS is useful for sharing directories of files between multiple users on the same network. For example, a group of users working on the same project can have access to the files for that project using a shared directory of the NFS file system (commonly known as an NFS share) mounted in the directory /myproject . To access the shared files, the user goes into the /myproject directory on his machine. There are no passwords to enter or special commands to remember. Users work as if the directory is on their local machines.

Commands:
Making open source more inclusive Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright's message . The best way to become familiar with a new programming language or a technology is to create a "Hello World" application. You can create a "Hello World" application for JBoss EAP by using Maven as the project management tool. To create a Hello World application, deploy it and test the deployment, follow these procedures: Bare metal deployment Creating a Maven project for a hello world application Creating a hello world servlet Deploying an application to a bare metal installation Adding the Maven dependencies and profile required for integration tests Testing an application deployed on JBoss EAP that is running on bare metal OpenShift Container Platform deployment Creating a Maven project for a hello world application Creating a hello world servlet Deploying an application to OpenShift Container Platform Adding the Maven dependencies and profile required for integration tests Testing an application deployed to JBoss EAP on OpenShift Container Platform

Commands:
Chapter 12. Kernel Kernel version in RHEL 7.6 Red Hat Enterprise Linux 7.6 is distributed with the kernel version 3.10.0-957. (BZ#1801759) The kdump FCoE target has been added into the kexec-tools documents This update adds the kdump Fibre Channel over Ethernet (FCoE) target into the kexec-tools documents. As a result, users now have better understanding about the state and details of kdump on FCoE target support. (BZ#1352763) The SCHED_DEADLINE scheduler class enabled This update adds support for the SCHED_DEADLINE scheduler class for the Linux kernel. The scheduler enables predictable task scheduling based on application deadlines. SCHED_DEADLINE benefits periodic workloads by guaranteeing timing isolation, which is not based only on a fixed priority but also on the applications' timing requirements. (BZ#1344565) User mount namespaces now fully supported The mount namespaces feature, previously available as a Technology Preview, is now fully supported. (BZ#1350553) kernel.shmmax and kernel.shmall updated to kernel defaults on IBM Z Previously, applications that required a large amount of memory in some cases terminated unexpectedly due to low values of the kernel.shmmax and kernel.shmall parameters on IBM Z. This update aligns the values of kernel.shmmax and kernel.shmall with kernel defaults, which helps avoid the described crashes. (BZ# 1493069 ) Updated aQuantia Corporation atlantic Network driver The aQuantia Corporation Network driver, atlantic.ko.xz , has been updated to version 2.0.2.1-kern and it is now fully supported. (BZ#1451438) Thunderbolt 3 is now supported This update adds support for the Thunderbolt 3 interface. (BZ#1620372) Intel(R) Omni-Path Architecture (OPA) Host Software Intel Omni-Path Architecture (OPA) host software is fully supported in Red Hat Enterprise Linux 7.6. Intel OPA provides Host Fabric Interface (HFI) hardware with initialization and setup for high performance data transfers (high bandwidth, high message rate, low latency) between compute and I/O nodes in a clustered environment. For instructions on installing Intel Omni-Path Architecture documentation, see: https://www.intel.com/content/dam/support/us/en/documents/network-and-i-o/fabric-products/Intel_OP_Software_RHEL_7_6_RN_K34562.pdf (BZ# 1627126 ) opal-prd rebased to version 6.0.4 on the little-endian variant of IBM POWER Systems On the little-endian variant of IBM POWER Systems, the opal-prd packages have been upgraded to upstream version 6.0.4, which provides a number of bug fixes and enhancements over the version. For example: Performance in High Performance Computing (HPC) environments has been improved. The powernv_flash module is now explicitly loaded on systems based on Baseboard Management Controller (BMC), which ensures that the flash device is created before the opal-prd daemon starts. Error on the first failure for soft or hard offline is no longer displayed by the opal-prd daemon. (BZ# 1564097 , BZ#1537001)

Commands:
Chapter 25. Uninstalling the integrated IdM DNS service from an IdM server If you have more than one server with integrated DNS in an Identity Management (IdM) deployment, you might decide to remove the integrated DNS service from one of the servers. To do this, you must first decommission the IdM server completely before re-installing IdM on it, this time without the integrated DNS. Note While you can add the DNS role to an IdM server, IdM does not provide a method to remove only the DNS role from an IdM server: the ipa-dns-install command does not have an --uninstall option. Prerequisites You have integrated DNS installed on an IdM server. This is not the last integrated DNS service in your IdM topology. Procedure Identify the redundant DNS service and follow the procedure in Uninstalling an IdM server on the IdM replica that hosts this service. On the same host, follow the procedure in either Without integrated DNS, with an integrated CA as the root CA or Without integrated DNS, with an external CA as the root CA , depending on your use case.

Commands:
40.2.2.2. Unit Masks If the cpu_type is not timer , unit masks may also be required to further define the event. Unit masks for each event are listed with the op_help command. The values for each unit mask are listed in hexadecimal format. To specify more than one unit mask, the hexadecimal values must be combined using a bitwise or operation.

Commands:
opcontrol --event= <event-name> : <sample-rate> : <unit-mask>
Chapter 32. Uninstalling the IdM CA service from an IdM server If you have more than four Identity Management (IdM) replicas with the CA Role in your topology and you run into performance problems due to redundant certificate replication, remove redundant CA service instances from IdM replicas. To do this, you must first decommission the affected IdM replicas completely before re-installing IdM on them, this time without the CA service. Note While you can add the CA role to an IdM replica, IdM does not provide a method to remove only the CA role from an IdM replica: the ipa-ca-install command does not have an --uninstall option. Prerequisites You have the IdM CA service installed on more than four IdM servers in your topology. Procedure Identify the redundant CA service and follow the procedure in Uninstalling an IdM server on the IdM replica that hosts this service. On the same host, follow the procedure in Installing an IdM server: With integrated DNS, without a CA .

Commands:
Chapter 2. Learn more about ROSA with HCP Red Hat OpenShift Service on AWS (ROSA) with hosted control planes (HCP) offers a reduced-cost solution to create a managed ROSA cluster with a focus on efficiency. You can quickly create a new cluster and deploy applications in minutes. 2.1. Key features of ROSA with HCP ROSA with HCP requires a minimum of only two nodes, making it ideal for smaller projects while still being able to scale to support larger projects and enterprises. The underlying control plane infrastructure is fully managed. Control plane components, such as the API server and etcd database, are hosted in a Red Hat-owned AWS account. Provisioning time is approximately 10 minutes. Customers can upgrade the control plane and machine pools separately, which means they do not have to shut down the entire cluster during upgrades. 2.2. Getting started with ROSA with HCP Use the following sections to find content to help you learn about and use ROSA with HCP. 2.2.1. Architect Learn about ROSA with HCP Plan ROSA with HCP deployment Additional resources Architecture overview Back up and restore ROSA with HCP life cycle ROSA with HCP architecture ROSA with HCP service definition Getting support 2.2.2. Cluster Administrator Learn about ROSA with HCP Deploy ROSA with HCP Manage ROSA with HCP Additional resources ROSA with HCP architecture Installing ROSA with HCP Getting Support OpenShift Interactive Learning Portal Storage Monitoring overview ROSA with HCP life cycle Back up and restore 2.2.3. Developer Learn about application development in ROSA with HCP Deploy applications Additional resources Red Hat Developers site Building applications overview Getting support Red Hat OpenShift Dev Spaces (formerly Red Hat CodeReady Workspaces) Operators overview Images Developer-focused CLI

Commands:
Chapter 2. APIcast operator-based upgrade guide: from 2.14 to 2.15 Upgrading APIcast from 2.14 to 2.15 in an operator-based installation helps you use the APIcast API gateway to integrate your internal and external application programming interfaces (APIs) services with 3scale. Important In order to understand the required conditions and procedure, read the entire upgrade guide before applying the listed steps. The upgrade process disrupts the provision of the service until the procedure finishes. Due to this disruption, make sure to have a maintenance window. 2.1. Prerequisites to perform the upgrade To perform the upgrade of APIcast from 2.14 to 2.15 in an operator-based installation, the following required prerequisites must already be in place: An OpenShift Container Platform (OCP) 4.12, 4.13, 4.14, 4.15, 4.16, or 4.17 cluster with administrator access. Ensure that your OCP environment is upgraded to at least version 4.12, which is the minimal requirement for proceeding with an APIcast update. APIcast 2.14 previously deployed via the APIcast operator. Make sure the latest CSV of the threescale-2.14 channel is in use. To check it: If the approval setting for the subscription is automatic , you should already be in the latest CSV version of the channel. If the approval setting for the subscription is manual , make sure you approve all pending InstallPlans and have the latest CSV version. Keep in mind if there is a pending install plan, there might be more pending install plans, which will only be shown after the existing pending plan has been installed. 2.2. Upgrading APIcast from 2.14 to 2.15 in an operator-based installation Upgrade APIcast from 2.14 to 2.15 in an operator-based installation so that APIcast can function as the API gateway in your 3scale installation. Procedure Log in to the OCP console using the account with administrator privileges. Select the project where the APIcast operator has been deployed. Click Operators > Installed Operators . In Subscription > Channel , select Red Hat Integration - 3scale APIcast gateway . Edit the channel of the subscription by selecting the threescale-2.15 channel and save the changes. This will start the upgrade process. Query the pods status on the project until you see all the new versions are running and ready without errors: USD oc get pods -n <apicast_namespace> Note The pods might have temporary errors during the upgrade process. The time required to upgrade pods can vary from 5-10 minutes. Check the status of the APIcast objects and get the YAML content by running the following command: USD oc get apicast <myapicast> -n <apicast_namespace> -o yaml The new annotations with the values should be as follows: After you have performed all steps, the APIcast upgrade from 2.14 to 2.15 in an operator-based deployment is complete.

Commands:
oc get pods -n <apicast_namespace>
oc get apicast <myapicast> -n <apicast_namespace> -o yaml
apicast.apps.3scale.net/operator-version: "0.12.x"