mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Planned changes to naming convention for Windows build artifacts From October 2024 onward, Red Hat plans to introduce naming changes for some files that are distributed as part of Red Hat build of OpenJDK releases for Windows Server platforms. These file naming changes will affect both the .zip archive and .msi installers that Red Hat provides for the JDK, JRE and debuginfo packages for Red Hat build of OpenJDK versions 8, 11, and 17. The aim of this change is to adopt a common naming convention that is consistent across all versions of OpenJDK that Red Hat supports. Red Hat build of OpenJDK versions 8, 11, and 17 will be aligned with the naming convention that Red Hat has already adopted for Red Hat build of OpenJDK 21. This means that Red Hat build of OpenJDK 21 will not require any naming changes. These planned changes do not affect the files for the Linux portable builds of any Red Hat build of OpenJDK version. Red Hat build of OpenJDK 11.0.24 is the last release where Red Hat plans to use the old naming convention for Windows artifacts. The following list provides an example of how the planned naming changes will affect each file for future releases of Red Hat build of OpenJDK 11: MSI installer for JDK package Old file name: java-11-openjdk- <version> .windows.redhat.x86_64.msi New file name: java-11-openjdk- <version> .win.jdk.x86_64.msi .zip archive for JDK package Old file name: java-11-openjdk- <version> .windows.redhat.x86_64.zip New file name: java-11-openjdk- <version> .win.jdk.x86_64.zip MSI installer for JRE package Old file name: java-11-openjdk-jre- <version> .windows.redhat.x86_64.msi New file name: java-11-openjdk- <version> .win.jre.x86_64.msi .zip archive for for JRE package Old file name: java-11-openjdk-jre- <version> .windows.redhat.x86_64.zip New file name: java-11-openjdk- <version> .win.jre.x86_64.zip .zip archive for debuginfo package Old file name: java-11-openjdk- <version> .windows.redhat.x86_64.debuginfo.zip New file name: java-11-openjdk- <version> .win.debuginfo.x86_64.zip

Commands:
17.8. Examples of Common Scenarios This section demonstrates different virtual networking modes and provides some example scenarios. 17.8.1. Bridged Mode Bridged mode operates on Layer 2 of the OSI model. When used, all of the guest virtual machines will appear on the same subnet as the host physical machine. The most common use cases for bridged mode include: Deploying guest virtual machines in an existing network alongside host physical machines making the difference between virtual and physical machines transparent to the end user. Deploying guest virtual machines without making any changes to existing physical network configuration settings. Deploying guest virtual machines which must be easily accessible to an existing physical network. Placing guest virtual machines on a physical network where they must access services within an existing broadcast domain, such as DHCP. Connecting guest virtual machines to an exsting network where VLANs are used. 17.8.2. Routed Mode DMZ Consider a network where one or more nodes are placed in a controlled sub-network for security reasons. The deployment of a special sub-network such as this is a common practice, and the sub-network is known as a DMZ. See the following diagram for more details on this layout: Figure 17.8. Sample DMZ configuration Host physical machines in a DMZ typically provide services to WAN (external) host physical machines as well as LAN (internal) host physical machines. As this requires them to be accessible from multiple locations, and considering that these locations are controlled and operated in different ways based on their security and trust level, routed mode is the best configuration for this environment. Virtual Server Hosting Consider a virtual server hosting company that has several host physical machines, each with two physical network connections. One interface is used for management and accounting, the other is for the virtual machines to connect through. Each guest has its own public IP address, but the host physical machines use private IP address as management of the guests can only be performed by internal administrators. See the following diagram to understand this scenario: Figure 17.9. Virtual server hosting sample configuration 17.8.3. NAT Mode NAT (Network Address Translation) mode is the default mode. It can be used for testing when there is no need for direct network visibility. 17.8.4. Isolated Mode Isolated mode allows virtual machines to communicate with each other only. They are unable to interact with the physical network.

Commands:
3.4. Configuring luci with /etc/sysconfig/luci As of the Red Hat Enterprise Linux 6.1 release, you can configure some aspects of luci 's behavior by means of the /etc/sysconfig/luci file. The parameters you can change with this file include auxiliary settings of the running environment used by the init script as well as server configuration. In addition, you can edit this file to modify some application configuration parameters. There are instructions within the file itself describing which configuration parameters you can change by editing this file. In order to protect the intended format, you should not change the non-configuration lines of the /etc/sysconfig/luci file when you edit the file. Additionally, you should take care to follow the required syntax for this file, particularly for the INITSCRIPT section which does not allow for white spaces around the equal sign and requires that you use quotation marks to enclose strings containing white spaces. The following example shows how to change the port at which luci is being served by editing the /etc/sysconfig/luci file. Uncomment the following line in the /etc/sysconfig/luci file: Replace 4443 with the desired port number, which must be higher than or equal to 1024 (not a privileged port). For example, you can edit that line of the file as follows to set the port at which luci is being served to 8084 (commenting the line out again would have the same affect, as this is the default value). Restart the luci service for the changes to take effect. As the Red Hat Enterprise Linux 6.6 release, you can implement a fine-grained control over the ciphers behind the secured connection between luci and the web browser with the ssl_cipher_list configuration parameter in /etc/sysconfig/luci . This parameter can be used to impose restrictions as expressed with OpenSSL cipher notation. Important When you modify a configuration parameter in the /etc/sysconfig/luci file to redefine a default value, you should take care to use the new value in place of the documented default value. For example, when you modify the port at which luci is being served, make sure that you specify the modified value when you enable an IP port for luci , as described in Section 3.3.2, "Enabling the IP Port for luci " . Modified port and host parameters will automatically be reflected in the URL displayed when the luci service starts, as described in Section 4.2, "Starting luci " . You should use this URL to access luci . For more complete information on the parameters you can configure with the /etc/sysconfig/luci file, refer to the documentation within the file itself.

Commands:
#port = 4443
port = 8084
Chapter 33. Viewing 3scale API Management built-in traffic analytics for applications To identify accounts that need support and operations that warrant enhancements, view visual information on the traffic of an application. Each application using an API has a traffic trace in the 3scale system, which can be viewed from the Admin Portal as well as recovered by an API. Prerequisties A 3scale developer account A 3scale application with API credentials Procedure Navigate to the application for which you want to view analytics. You can find the application from Audience > Accounts > Listing or Audience > Applications > Listing under the Applications tab. Alternatively, you can search for an application by following the steps described in the finding applications tutorial . After you have located the application, you will see an overview page with information about the application, as shown in the following image: Table 33.1. The items labeled in the image correspond to the following information Number Application information 1 The name of the application given by the developer 2 Meta data captured for the application (learn how to set which data to capture in the advanced section) 3 The status of the application - is it live or suspended? 4 The current API identifiers, keys, and certificates that the application has. The view varies depending on what authentication method you are using to integrate the API into 3scale. 5 A summary of traffic statistics for the application 6 Information on which application plan the application is on and which rate limits apply. Click the Analytics link above the application name. The usage charts are displayed for the application. Controlling the metrics, methods, and time range allows you to check different types of data about the application.

Commands:
Chapter 5. Downloading the test plan from Red Hat Certification Portal Procedure Log in to Red Hat Certification portal . Search for the case number related to your product certification, and copy it. For example, 02887238. Click Cases enter the product case number. Optional: Click Test Plans . The test plan displays a list of components that will be tested during the test run. Click Download Test Plan . steps If you plan to use Cockpit to run the tests, see Chapter 6, Configuring the system and running tests by using Cockpit . If you plan to use CLI to run the tests, see Chapter 7, Configuring the system and running tests by using RHCert CLI Tool .

Commands:
Chapter 6. The Externalizable API An Externalizer is a class that can: Marshall a given object type to a byte array. Unmarshall the contents of a byte array into an instance of the object type. Externalizers are used by Red Hat JBoss Data Grid and allow users to specify how their object types are serialized. The marshalling infrastructure used in JBoss Data Grid builds upon JBoss Marshalling and provides efficient payload delivery and allows the stream to be cached. The stream caching allows data to be accessed multiple times, whereas normally a stream can only be read once. The Externalizable interface uses and extends serialization. This interface is used to control serialization and deserialization in JBoss Data Grid. Report a bug 6.1. Customize Externalizers As a default in Red Hat JBoss Data Grid, all objects used in a distributed or replicated cache must be serializable. The default Java serialization mechanism can result in network and performance inefficiency. Additional concerns include serialization versioning and backwards compatibility. For enhanced throughput, performance or to enforce specific object compatibility, use a customized externalizer. Customized externalizers for JBoss Data Grid can be used in one of two ways: Use an Externalizable Interface. For details, see Chapter 6, The Externalizable API . Use an advanced externalizer. Report a bug

Commands:
17.5. Distributed Task Execution Policy The DistributedTaskExecutionPolicy allows tasks to specify a custom execution policy across the Red Hat JBoss Data Grid cluster, by scoping execution of tasks to a subset of nodes. For example, DistributedTaskExecutionPolicy can be used to manage task execution in the following cases: where a task is to be exclusively executed on a local network site instead of a backup remote network center. where only a dedicated subset of a certain JBoss Data Grid rack nodes are required for specific task execution. Example 17.5. Using Rack Nodes to Execute a Specific Task Report a bug

Commands:
DistributedExecutorService des = new DefaultExecutorService(cache); DistributedTaskBuilder<Boolean> taskBuilder = des.createDistributedTaskBuilder(new SomeCallable()); taskBuilder.executionPolicy(DistributedTaskExecutionPolicy.SAME_RACK); DistributedTask<Boolean> distributedTask = taskBuilder.build(); Future<Boolean> future = des.submit(distributedTask); Boolean r = future.get();
Chapter 6. Premigration checklists Before you migrate your application workloads with the Migration Toolkit for Containers (MTC), review the following checklists. 6.1. Cluster health checklist ❏ The clusters meet the minimum hardware requirements for the specific platform and installation method, for example, on bare metal . ❏ All MTC prerequisites are met. ❏ All nodes have an active OpenShift Container Platform subscription. ❏ You have verified node health . ❏ The identity provider is working. ❏ The migration network has a minimum throughput of 10 Gbps. ❏ The clusters have sufficient resources for migration. Note Clusters require additional memory, CPUs, and storage in order to run a migration on top of normal workloads. Actual resource requirements depend on the number of Kubernetes resources being migrated in a single migration plan. You must test migrations in a non-production environment in order to estimate the resource requirements. ❏ The etcd disk performance of the clusters has been checked with fio . 6.2. Source cluster checklist ❏ You have checked for persistent volumes (PVs) with abnormal configurations stuck in a Terminating state by running the following command: USD oc get pv ❏ You have checked for pods whose status is other than Running or Completed by running the following command: USD oc get pods --all-namespaces | egrep -v 'Running | Completed' ❏ You have checked for pods with a high restart count by running the following command: USD oc get pods --all-namespaces --field-selector=status.phase=Running \ -o json | jq '.items[]|select(any( .status.containerStatuses[]; \ .restartCount > 3))|.metadata.name' Even if the pods are in a Running state, a high restart count might indicate underlying problems. ❏ The cluster certificates are valid for the duration of the migration process. ❏ You have checked for pending certificate-signing requests by running the following command: USD oc get csr -A | grep pending -i ❏ The registry uses a recommended storage type . ❏ You can read and write images to the registry. ❏ The etcd cluster is healthy. ❏ The average API server response time on the source cluster is less than 50 ms. 6.3. Target cluster checklist ❏ The cluster has the correct network configuration and permissions to access external services, for example, databases, source code repositories, container image registries, and CI/CD tools. ❏ External applications and services that use services provided by the cluster have the correct network configuration and permissions to access the cluster. ❏ Internal container image dependencies are met. ❏ The target cluster and the replication repository have sufficient storage space.

Commands:
oc get pv
oc get pods --all-namespaces | egrep -v 'Running | Completed'
oc get pods --all-namespaces --field-selector=status.phase=Running -o json | jq '.items[]|select(any( .status.containerStatuses[]; .restartCount > 3))|.metadata.name'
oc get csr -A | grep pending -i
Chapter 7. Configuring kube-rbac-proxy for Knative for Apache Kafka The kube-rbac-proxy component provides internal authentication and authorization capabilities for Knative for Apache Kafka. 7.1. Configuring kube-rbac-proxy resources for Knative for Apache Kafka You can globally override resource allocation for the kube-rbac-proxy container by using the OpenShift Serverless Operator CR. Note You can also override resource allocation for a specific deployment. The following configuration sets Knative Kafka kube-rbac-proxy minimum and maximum CPU and memory allocation: KnativeKafka CR example apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: name: knative-kafka namespace: knative-kafka spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4 1 Sets minimum CPU allocation. 2 Sets minimum RAM allocation. 3 Sets maximum CPU allocation. 4 Sets maximum RAM allocation.

Commands:
apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: name: knative-kafka namespace: knative-kafka spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4
Chapter 1. How to Upgrade An in-place upgrade is the recommended and supported way to upgrade your system to the major version of RHEL. 1.1. How to upgrade from Red Hat Enterprise Linux 6 The Upgrading from RHEL 6 to RHEL 7 guide describes steps for an in-place upgrade from RHEL 6 to RHEL 7. The supported in-place upgrade path is from RHEL 6.10 to RHEL 7.9. If you are using SAP HANA, follow How do I upgrade from RHEL 6 to RHEL 7 with SAP HANA instead. Note that the upgrade path for RHEL with SAP HANA might differ. The process of upgrading from RHEL 6 to RHEL 7 consists of the following steps: Check that Red Hat supports the upgrade of your system. Prepare your system for the upgrade by installing required repositories and packages and by removing unsupported packages. Check your system for problems that might affect your upgrade using the Preupgrade Assistant. Upgrade your system by running the Red Hat Upgrade Tool.

Commands:
probe::scsi.iodone Name probe::scsi.iodone - SCSI command completed by low level driver and enqueued into the done queue. Synopsis Values device_state_str The current state of the device, as a string dev_id The scsi device id channel The channel number data_direction The data_direction specifies whether this command is from/to the device. lun The lun number host_no The host number data_direction_str Data direction, as a string device_state The current state of the device scsi_timer_pending 1 if a timer is pending on this request req_addr The current struct request pointer, as a number

Commands:
scsi.iodone
Preface Red Hat Ansible automation hub provides a place for Red Hat subscribers to quickly find and use content that is supported by Red Hat and our technology partners to deliver additional reassurance for the most demanding environments. The Ansible Galaxy client, ansible-galaxy , manages roles and collections from the command line. To ensure that the ansible-galaxy client uses certified, supported Ansible collections whenever possible, update your ansible.cfg file to use Red Hat automation hub as your primary source of Ansible collections. This guide walks you through the steps required to configure your ansible.cfg file to use Red Hat automation hub as the default source for certified Ansible collections content.

Commands:
Chapter 2. Authentication and Security 2.1. TLS/SSL Certification The Red Hat Virtualization Manager API requires Hypertext Transfer Protocol Secure (HTTPS) [1] for secure interaction with client software, such as the Manager's SDK and CLI components. This involves a process of obtaining a certificate from the Red Hat Virtualization Manager and importing it into the certificate store of your client. Important Obtain your certificate from the Red Hat Virtualization Manager using a secure network connection. Procedure 2.1. Obtaining a Certificate You can obtain a certificate from the Red Hat Virtualization Manager and transfer it to the client machine using one of three methods: Method 1 - Use a command line tool to download the certificate from the Manager. Examples of command line tools include cURL and Wget , both of which are available on multiple platforms. If using cURL : If using Wget : Method 2 - Use a web browser to navigate to the certificate located at: Depending on the chosen browser, the certificate either downloads or imports into the browser's keystore. If the browser downloads the certificate: save the file as rhvm.cer . If the browser imports the certificate: export it from the browser's certification options and save it as rhvm.cer . Method 3 - Log in to the Manager, export the certificate from the truststore and copy it to your client machine. Log in to the Manager as the root user. Export the certificate from the truststore using the Java keytool management utility: This creates a certificate file called rhvm.cer . Copy the certificate to the client machine using the scp command: Each of these methods results in a certificate file named rhvm.cer on your client machine. An API user imports this file into the certificate store of the client. Procedure 2.2. Importing a Certificate to a Client Importing a certificate to a client relies on how the client itself stores and interprets certificates. This guide contains some examples on importing certificates. For clients not using Network Security Services (NSS) or Java KeyStore (JKS), see your client documentation for more information on importing a certificate. [1] HTTPS is described in RFC 2818 HTTP Over TLS .

Commands:
curl -o rhvm.cer http:// [manager-fqdn] /ovirt-engine/services/pki-resource?resource=ca-certificate&format= X509-PEM-CA
wget -O rhvm.cer http:// [manager-fqdn] /ovirt-engine/services/pki-resource?resource=ca-certificate&format= X509-PEM-CA
http:// [manager-fqdn] /ovirt-engine/services/pki-resource?resource=ca-certificate&format= X509-PEM-CA
keytool -exportcert -keystore /etc/pki/ovirt-engine/.truststore -alias cacert -storepass mypass -file rhvm.cer
scp rhvm.cer [username] @ [client-machine] : [directory]
24.2. Configuring DHCP for Diskless Clients After configuring a tftp server, you need to set up a DHCP service on the same host machine. Refer to the Red Hat Enterprise Linux 6 Deployment Guide for instructions on how to set up a DHCP server. In addition, you should enable PXE booting on the DHCP server; to do this, add the following configuration to /etc/dhcp/dhcp.conf : Replace server-ip with the IP address of the host machine on which the tftp and DHCP services reside. Now that tftp and DHCP are configured, all that remains is to configure NFS and the exported file system; refer to Section 24.3, "Configuring an Exported File System for Diskless Clients" for instructions.

Commands:
allow booting; allow bootp; class "pxeclients" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; next-server server-ip ; filename "pxelinux.0"; }