mtpti5iD/redhat-docs_dataset huggingface dataset:
Installation overview OpenShift Container Platform 4.17 Overview content for installing OpenShift Container Platform Red Hat OpenShift Documentation Team

Commands:
oc get nodes
NAME STATUS ROLES AGE VERSION example-compute1.example.com Ready worker 13m v1.21.6+bb8d50a example-compute2.example.com Ready worker 13m v1.21.6+bb8d50a example-compute4.example.com Ready worker 14m v1.21.6+bb8d50a example-control1.example.com Ready master 52m v1.21.6+bb8d50a example-control2.example.com Ready master 55m v1.21.6+bb8d50a example-control3.example.com Ready master 55m v1.21.6+bb8d50a
oc get machines -A
NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
capabilities: baselineCapabilitySet: v4.11 1 additionalEnabledCapabilities: 2 - CSISnapshot - Console - Storage
oc get clusteringresses.ingress.openshift.io -n openshift-ingress-operator default -o yaml
oc get deployment -n openshift-ingress
oc get network/cluster -o jsonpath='{.status.clusterNetwork[*]}'
map[cidr:10.128.0.0/14 hostPrefix:23]
oc get clusterversion version -o jsonpath='{.spec.capabilities}{"\n"}{.status.capabilities}{"\n"}'
{"additionalEnabledCapabilities":["openshift-samples"],"baselineCapabilitySet":"None"} {"enabledCapabilities":["openshift-samples"],"knownCapabilities":["CSISnapshot","Console","Insights","Storage","baremetal","marketplace","openshift-samples"]}
oc patch clusterversion version --type merge -p '{"spec":{"capabilities":{"baselineCapabilitySet":"vCurrent"}}}' 1
oc get clusterversion version -o jsonpath='{.spec.capabilities.additionalEnabledCapabilities}{"\n"}'
openshift-samples
oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["openshift-samples", "marketplace"]}}}'
oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="ImplicitlyEnabledCapabilities")]}{"\n"}'
lastTransitionTime: 2022-07-22T03:14:35Z
message: The following capabilities could not be disabled: openshift-samples
reason: CapabilitiesImplicitlyEnabled
status: True
type: ImplicitlyEnabledCapabilities
oc adm release extract --registry-config "USD{pullsecret_file}" --command=openshift-install-fips --to "USD{extract_dir}" USD{RELEASE_IMAGE}
tar -xvf openshift-install-rhel9-amd64.tar.gz
Chapter 6. Disabling disaster recovery for a disaster recovery enabled application This section guides you to disable disaster recovery (DR) for an application deployed using Red Hat Advanced Cluster Management (RHACM). Disabling DR managed applications . Disabling DR discovered applications . 6.1. Disabling DR managed applications On the Hub cluster, navigate to All Clusters Applications . In the Overview tab, at the end of the protected application row from the action menu, select Manage disaster recovery . Click Remove disaster recovery . Click Confirm remove . Warning Your application will lose disaster recovery protection, preventing volume synchronization (replication) between clusters. Note The application continues to be visible in the Applications Overview menu but the Data policy is removed. 6.2. Disabling DR discovered applications In the RHACM console, navigate to All Clusters Data Services Protected applications tab. At the end of the application row, click on the Actions menu and choose Remove disaster recovery . Click Remove in the prompt. Warning Your application will lose disaster recovery protection, preventing volume synchronization (replication) between clusters. Note The application is no longer in the Protected applications tab once the DR is removed.

Commands:
Chapter 11. Enabling the Red Hat OpenShift Data Foundation console plugin Enable the console plugin option if it was not automatically enabled after you installed the OpenShift Data Foundation Operator. The console plugin provides a custom interface that is included in the Web Console. You can enable the console plugin option either from the graphical user interface (GUI) or command-line interface. Prerequisites You have administrative access to the OpenShift Web Console. OpenShift Data Foundation Operator is installed and running in the openshift-storage namespace. Procedure From user interface In the OpenShift Web Console, click Operators Installed Operators to view all the installed operators. Ensure that the Project selected is openshift-storage . Click on the OpenShift Data Foundation operator. Enable the console plugin option. In the Details tab, click the pencil icon under Console plugin . Select Enable , and click Save . From command-line interface Execute the following command to enable the console plugin option: Verification steps After the console plugin option is enabled, a pop-up with a message, Web console update is available appears on the GUI. Click Refresh web console from this pop-up for the console changes to reflect. In the Web Console, navigate to Storage and verify if OpenShift Data Foundation is available.

Commands:
oc patch console.operator cluster -n openshift-storage --type json -p '[{"op": "add", "path": "/spec/plugins", "value": ["odf-console"]}]'
8.5. Additional Resources The following are resources which explain more about network interfaces. 8.5.1. Installed Documentation /usr/share/doc/initscripts- <version> /sysconfig.txt - A guide to available options for network configuration files, including IPv6 options not covered in this chapter. /usr/share/doc/iproute- <version> /ip-cref.ps - This file contains a wealth of information about the ip command, which can be used to manipulate routing tables, among other things. Use the ggv or kghostview application to view this file.

Commands:
27.2.2. Running the At Service The At and Batch jobs are both picked by the atd service. This section provides information on how to start, stop, and restart the atd service, and shows how to enable it in a particular runlevel. For more information on the concept of runlevels and how to manage system services in Red Hat Enterprise Linux in general, see Chapter 12, Services and Daemons . 27.2.2.1. Starting and Stopping the At Service To determine if the service is running, use the command service atd status . To run the atd service in the current session, type the following at a shell prompt as root : service atd start To configure the service to start automatically at boot, use the following command: chkconfig atd on Note It is recommended to start the service at boot automatically. This command enables the service in runlevel 2, 3, 4, and 5. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, "Enabling and Disabling a Service" . 27.2.2.2. Stopping the At Service To stop the atd service, type the following at a shell prompt as root service atd stop To disable starting the service at boot time, use the following command: chkconfig atd off This command disables the service in all runlevels. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, "Enabling and Disabling a Service" . 27.2.2.3. Restarting the At Service To restart the atd service, type the following at a shell prompt: service atd restart This command stops the service and starts it again in quick succession.

Commands:
8.4.6. Using OpenSCAP to Remediate the System OpenSCAP allows to automatically remediate systems that have been found in a non-compliant state. For system remediation, an XCCDF file with instructions is required. The scap-security-guide package constains certain remediation instructions. System remediation consists of the following steps: OpenSCAP performs a regular XCCDF evaluation. An assessment of the results is performed by evaluating the OVAL definitions. Each rule that has failed is marked as a candidate for remediation. OpenSCAP searches for an appropriate fix element, resolves it, prepares the environment, and executes the fix script. Any output of the fix script is captured by OpenSCAP and stored within the rule-result element. The return value of the fix script is stored as well. Whenever OpenSCAP executes a fix script, it immediatelly evaluates the OVAL definition again (to verify that the fix script has been applied correctly). During this second run, if the OVAL evaluation returns success, the result of the rule is fixed , otherwise it is an error . Detailed results of the remediation are stored in an output XCCDF file. It contains two TestResult elements. The first TestResult element represents the scan prior to the remediation. The second TestResult is derived from the first one and contains remediation results. There are three modes of operation of OpenSCAP with regard to remediation: online, offline, and review. 8.4.6.1. OpenSCAP Online Remediation Online remediation executes fix elements at the time of scanning. Evaluation and remediation are performed as a part of a single command. To enable online remediation, use the --remediate command-line option. For example, to execute online remediation using the scap-security-guide package, run: The output of this command consists of two sections. The first section shows the result of the scan prior to the remediation, and the second section shows the result of the scan after applying the remediation. The second part can contain only fixed and error results. The fixed result indicates that the scan performed after the remediation passed. The error result indicates that even after applying the remediation, the evaluation still does not pass.

Commands:
~]USD oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdf-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
Chapter 2. What is deployed with AMQ Streams Apache Kafka components are provided for deployment to OpenShift with the AMQ Streams distribution. The Kafka components are generally run as clusters for availability. A typical deployment incorporating Kafka components might include: Kafka cluster of broker nodes ZooKeeper cluster of replicated ZooKeeper instances Kafka Connect cluster for external data connections Kafka MirrorMaker cluster to mirror the Kafka cluster in a secondary cluster Kafka Exporter to extract additional Kafka metrics data for monitoring Kafka Bridge to make HTTP-based requests to the Kafka cluster Not all of these components are mandatory, though you need Kafka and ZooKeeper as a minimum. Some components can be deployed without Kafka, such as MirrorMaker or Kafka Connect. 2.1. Order of deployment The required order of deployment to an OpenShift cluster is as follows: Deploy the Cluster operator to manage your Kafka cluster Deploy the Kafka cluster with the ZooKeeper cluster, and include the Topic Operator and User Operator in the deployment Optionally deploy: The Topic Operator and User Operator standalone if you did not deploy them with the Kafka cluster Kafka Connect Kafka MirrorMaker Kafka Bridge Components for the monitoring of metrics 2.2. Additional deployment configuration options The deployment procedures in this guide describe a deployment using the example installation YAML files provided with AMQ Streams. The procedures highlight any important configuration considerations, but they do not describe all the configuration options available. You can use custom resources to refine your deployment. You may wish to review the configuration options available for Kafka components before you deploy AMQ Streams. For more information on the configuration through custom resources, see Deployment configuration in the Using AMQ Streams on OpenShift guide. 2.2.1. Securing Kafka On deployment, the Cluster Operator automatically sets up TLS certificates for data encryption and authentication within your cluster. AMQ Streams provides additional configuration options for encryption , authentication and authorization , which are described in the Using AMQ Streams on OpenShift guide: Secure data exchange between the Kafka cluster and clients by Managing secure access to Kafka . Configure your deployment to use an authorization server to provide OAuth 2.0 authentication and OAuth 2.0 authorization . Secure Kafka using your own certificates . 2.2.2. Monitoring your deployment AMQ Streams supports additional deployment options to monitor your deployment. Extract metrics and monitor Kafka components by deploying Prometheus and Grafana with your Kafka cluster . Extract additional metrics, particularly related to monitoring consumer lag, by deploying Kafka Exporter with your Kafka cluster . Track messages end-to-end by setting up distributed tracing , as described in the Using AMQ Streams on OpenShift guide.

Commands:
6.6. Checking Client Operating Versions Different versions of Red Hat Gluster Storage support different features. Servers and clients identify the features that they are capable of supporting using an operating version number, or op-version . The cluster.op-version parameter sets the required operating version for all volumes in a cluster on the server side. Each client supports a range of operating versions that are identified by a minimum ( min-op-version ) and maximum ( max-op-version ) supported operating version. Check the operating versions of the clients connected to a given volume by running the following command: For Red Hat Gluster 3.2 and later Use all in place of the name of your volume if you want to see the operating versions of clients connected to all volumes in the cluster. Before Red Hat Gluster Storage 3.2: Perform a state dump for the volume whose clients you want to check. Locate the state dump directory Locate the state dump file and grep for client information.

Commands:
gluster volume status volname clients
gluster volume statedump volname
gluster --print-statedumpdir
grep -A4 "identifier= client_ip " statedumpfile
14.3.7. Viewing an SSH CA Certificate To view a certificate, use the -L to list the contents. For example, for a user's certificate: To vew a host certificate:

Commands:
~]USD ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub /home/user1/.ssh/id_rsa-cert.pub: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT 3c:9d:42:ed:65:b6:0f:18:bf:52:77:c6:02:0e:e5:86 Signing CA: RSA b1:8e:0b:ce:fe:1b:67:59:f1:74:cd:32:af:5f:c6:e8 Key ID: "user1" Serial: 0 Valid: from 2015-05-27T00:09:16 to 2016-06-09T00:09:16 Principals: user1 Critical Options: (none) Extensions: permit-X11-forwarding permit-agent-forwarding permit-port-forwarding permit-pty permit-user-rc
~]# ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub /etc/ssh/ssh_host_rsa_key-cert.pub: Type: ssh-rsa-cert-v01@openssh.com host certificate Public key: RSA-CERT 1d:71:61:50:05:9b:ec:64:34:27:a5:cc:67:24:03:23 Signing CA: RSA e4:d5:d1:4f:6b:fd:a2:e3:4e:5a:73:52:91:0b:b7:7a Key ID: "host_name" Serial: 0 Valid: from 2015-05-26T17:19:01 to 2016-06-08T17:19:01 Principals: host_name.example.com Critical Options: (none) Extensions: (none)
13.8. Date & Time To configure time zone, date, and optionally settings for network time, select Date & Time at the Installation Summary screen. There are three ways for you to select a time zone: Using your mouse, click on the interactive map to select a specific city. A red pin appears indicating your selection. You can also scroll through the Region and City drop-down menus at the top of the screen to select your time zone. Select Etc at the bottom of the Region drop-down menu, then select your time zone in the menu adjusted to GMT/UTC, for example GMT+1 . If your city is not available on the map or in the drop-down menu, select the nearest major city in the same time zone. Alternatively you can use a Kickstart file, which will allow you to specify some additional time zones which are not available in the graphical interface. See the timezone command in timezone (required) for details. Note The list of available cities and regions comes from the Time Zone Database (tzdata) public domain, which is maintained by the Internet Assigned Numbers Authority (IANA). Red Hat cannot add cities or regions into this database. You can find more information at the official website, available at http://www.iana.org/time-zones . Specify a time zone even if you plan to use NTP (Network Time Protocol) to maintain the accuracy of the system clock. If you are connected to the network, the Network Time switch will be enabled. To set the date and time using NTP, leave the Network Time switch in the ON position and click the configuration icon to select which NTP servers Red Hat Enterprise Linux should use. To set the date and time manually, move the switch to the OFF position. The system clock should use your time zone selection to display the correct date and time at the bottom of the screen. If they are still incorrect, adjust them manually. Note that NTP servers might be unavailable at the time of installation. In such a case, enabling them will not set the time automatically. When the servers become available, the date and time will update. Once you have made your selection, click Done to return to the Installation Summary screen. Note To change your time zone configuration after you have completed the installation, visit the Date & Time section of the Settings dialog window.

Commands:
Chapter 12. Accessing the dashboard After you have installed OpenShift AI and added users, you can access the URL for your OpenShift AI console and share the URL with the users to let them log in and work on their models. Prerequisites You have installed OpenShift AI on your OpenShift Dedicated or Red Hat OpenShift Service on Amazon Web Services (ROSA) cluster. You have added at least one user to the user group for OpenShift AI as described in Adding users . Procedure Log in to OpenShift web console. Click the application launcher ( ). Right-click on Red Hat OpenShift AI and copy the URL for your OpenShift AI instance. Provide this instance URL to your data scientists to let them log in to OpenShift AI. Verification Confirm that you and your users can log in to OpenShift AI by using the instance URL. Additional resources Logging in to OpenShift AI Adding users

Commands:
Chapter 27. Adding and removing tracepoints from a running perf collector without stopping or restarting perf By using the control pipe interface to enable and disable different tracepoints in a running perf collector, you can dynamically adjust what data you are collecting without having to stop or restart perf . This ensures you do not lose performance data that would have otherwise been recorded during the stopping or restarting process. 27.1. Adding tracepoints to a running perf collector without stopping or restarting perf Add tracepoints to a running perf collector using the control pipe interface to adjust the data you are recording without having to stop perf and losing performance data. Prerequisites You have the perf user space tool installed as described in Installing perf . Procedure Configure the control pipe interface: Run perf record with the control file setup and events you are interested in enabling: In this example, declaring 'sched:*' after the -e option starts perf record with scheduler events. In a second terminal, start the read side of the control pipe: Starting the read side of the control pipe triggers the following message in the first terminal: In a third terminal, enable a tracepoint using the control file: This command triggers perf to scan the current event list in the control file for the declared event. If the event is present, the tracepoint is enabled and the following message appears in the first terminal: Once the tracepoint is enabled, the second terminal displays the output from perf detecting the tracepoint: 27.2. Removing tracepoints from a running perf collector without stopping or restarting perf Remove tracepoints from a running perf collector using the control pipe interface to reduce the scope of data you are collecting without having to stop perf and losing performance data. Prerequisites You have the perf user space tool installed as described in Installing perf . You have added tracepoints to a running perf collector via the control pipe interface. For more information, see Adding tracepoints to a running perf collector without stopping or restarting perf . Procedure Remove the tracepoint: Note This example assumes you have previously loaded scheduler events into the control file and enabled the tracepoint sched:sched_process_fork . This command triggers perf to scan the current event list in the control file for the declared event. If the event is present, the tracepoint is disabled and the following message appears in the terminal used to configure the control pipe:

Commands:
mkfifo control ack perf.pipe
perf record --control=fifo:control,ack -D -1 --no-buffering -e ' sched:* ' -o - > perf.pipe
cat perf.pipe | perf --no-pager script -i -
Events disabled
echo 'enable sched:sched_process_fork ' > control
event sched:sched_process_fork enabled
bash 33349 [034] 149587.674295: sched:sched_process_fork: comm=bash pid=33349 child_comm=bash child_pid=34056
echo 'disable sched:sched_process_fork ' > control
event sched:sched_process_fork disabled
Chapter 2. Eclipse Temurin features Eclipse Temurin does not contain structural changes from the upstream distribution of OpenJDK. For the list of changes and security fixes that the latest OpenJDK 17 release of Eclipse Temurin includes, see OpenJDK 17.0.7 Released . OpenJDK enhancements OpenJDK 17 provides enhancements to features originally created in releases of OpenJDK. Certigna (Dhimyotis) root certificate authority (CA) certificate added In release OpenJDK 17.0.7, the cacerts truststore includes the Certigna (Dhimyotis) root certificate: Name: Certigna (Dhimyotis) Alias name: certignarootca Distinguished name: CN=Certigna, O=Dhimyotis, C=FR See JDK-8245654 (JDK Bug System) . New Java Flight Recorder (JFR) event jdk.InitialSecurityProperty With OpenJDK 17.0.7, the initial security properties that the java.security.Security class loads are now accessible in the new JFR event, jdk.InitialSecurityProperty . The jdk.InitialSecurityProperty event contains the following two fields: Key: The security property key. Value: The corresponding security property value. By using this new event and the existing jdk.SecurityPropertyModification event, you can now monitor security properties throughout their lifecycle. In this release, you can also print initial security properties to the standard error output stream when the -Djava.security.debug=properties property is passed to the Java virtual machine. See JDK-8292177 (JDK Bug System) . Error thrown if java.security file fails to load In releases, if OpenJDK could not load the java.security file, a hard-coded set of security properties was used. This set of properties was not fully maintained and it was unclear to the user when they were being used. Now, with OpenJDK 17.0.7, if OpenJDK cannot load the java.security file, OpenJDK displays an InternalError error message. See JDK-8155246 (JDK Bug System) . listRoots method returns all available drives on Windows In releases, the java.io.File.listRoots() method on Windows systems filtered out any disk drives that were not accessible or did not have media loaded. However, this filtering led to observable performance issues. With release OpenJDK 17.0.7, the listRoots method returns all available disk drives unfiltered. See JDK-8208077 (JDK Bug System) . Enhanced Swing platform support In earlier releases of OpenJDK, HTML object tags rendered embedded in Swing HTML components. With release OpenJDK 17.0.7, rendering only occurs if you set the new system property swing.html.object to true. By default, the swing.html.object property is set to false. JDK bug system reference ID: JDK-8296832. Revised on 2024-05-03 15:37:24 UTC

Commands: