mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. Disabling the web console in OpenShift Container Platform You can disable the OpenShift Container Platform web console. 9.1. Prerequisites Deploy an OpenShift Container Platform cluster. 9.2. Disabling the web console You can disable the web console by editing the consoles.operator.openshift.io resource. Edit the consoles.operator.openshift.io resource: USD oc edit consoles.operator.openshift.io cluster The following example displays the parameters from this resource that you can modify: apiVersion: operator.openshift.io/v1 kind: Console metadata: name: cluster spec: managementState: Removed 1 1 Set the managementState parameter value to Removed to disable the web console. The other valid values for this parameter are Managed , which enables the console under the cluster's control, and Unmanaged , which means that you are taking control of web console management.

Commands:
oc edit consoles.operator.openshift.io cluster
apiVersion: operator.openshift.io/v1 kind: Console metadata: name: cluster spec: managementState: Removed 1
Chapter 114. KafkaUserTlsClientAuthentication schema reference Used in: KafkaUserSpec The type property is a discriminator that distinguishes use of the KafkaUserTlsClientAuthentication type from KafkaUserTlsExternalClientAuthentication , KafkaUserScramSha512ClientAuthentication . It must have the value tls for the type KafkaUserTlsClientAuthentication . Property Property type Description type string Must be tls .

Commands:
4.2. Configuring Timeout Values for a Cluster When you create a cluster with the pcs cluster setup command, timeout values for the cluster are set to default values that should be suitable for most cluster configurations. If you system requires different timeout values, however, you can modify these values with the pcs cluster setup options summarized in Table 4.1, "Timeout Options" Table 4.1. Timeout Options Option Description --token timeout Sets time in milliseconds until a token loss is declared after not receiving a token (default 1000 ms) --join timeout sets time in milliseconds to wait for join messages (default 50 ms) --consensus timeout sets time in milliseconds to wait for consensus to be achieved before starting a new round of member- ship configuration (default 1200 ms) --miss_count_const count sets the maximum number of times on receipt of a token a message is checked for retransmission before a retransmission occurs (default 5 messages) --fail_recv_const failures specifies how many rotations of the token without receiving any messages when messages should be received may occur before a new configuration is formed (default 2500 failures) For example, the following command creates the cluster new_cluster and sets the token timeout value to 10000 milliseconds (10 seconds) and the join timeout value to 100 milliseconds.

Commands:
pcs cluster setup --name new_cluster nodeA nodeB --token 10000 --join 100
Chapter 16. Tuning serving configuration 16.1. Overriding Knative Serving system deployment configurations You can override the default configurations for some specific deployments by modifying the workloads spec in the KnativeServing custom resources (CRs). 16.1.1. Overriding system deployment configurations Currently, overriding default configuration settings is supported for the resources , replicas , labels , annotations , and nodeSelector fields, as well as for the readiness and liveness fields for probes. In the following example, a KnativeServing CR overrides the webhook deployment so that: The readiness probe timeout for net-kourier-controller is set to be 10 seconds. The deployment has specified CPU and memory resource limits. The deployment has 3 replicas. The example-label: label label is added. The example-annotation: annotation annotation is added. The nodeSelector field is set to select nodes with the disktype: hdd label. Note The KnativeServing CR label and annotation settings override the deployment's labels and annotations for both the deployment itself and the resulting pods. KnativeServing CR example apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: ks namespace: knative-serving spec: high-availability: replicas: 2 workloads: - name: net-kourier-controller readinessProbes: 1 - container: controller timeoutSeconds: 10 - name: webhook resources: - container: webhook requests: cpu: 300m memory: 60Mi limits: cpu: 1000m memory: 1000Mi replicas: 3 labels: example-label: label annotations: example-annotation: annotation nodeSelector: disktype: hdd 1 You can use the readiness and liveness probe overrides to override all fields of a probe in a container of a deployment as specified in the Kubernetes API except for the fields related to the probe handler: exec , grpc , httpGet , and tcpSocket . Additional resources Probe configuration section of the Kubernetes API documentation

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: ks namespace: knative-serving spec: high-availability: replicas: 2 workloads: - name: net-kourier-controller readinessProbes: 1 - container: controller timeoutSeconds: 10 - name: webhook resources: - container: webhook requests: cpu: 300m memory: 60Mi limits: cpu: 1000m memory: 1000Mi replicas: 3 labels: example-label: label annotations: example-annotation: annotation nodeSelector: disktype: hdd
Chapter 14. Red Hat Enterprise Linux Atomic Host 7.6.4 14.1. Atomic Host OStree update : New Tree Version: 7.6.4 (hash: 177b1ebe1765f4fbd75c90bfb3781f7ccd39e84367eea5e0afe3977704ab66ea) Changes since Tree Version 7.6.3 (hash: d3fc043862e78ecb2b4f3f16938414039bc0a29a069ab6b6dfb3d4ae3a1494e8) Updated packages : microdnf-2-7.el7 redhat-release-atomic-host-7.6-20190329.0.atomic.el7.0 14.2. Extras Updated packages : driverctl-0.108-1.el7_6 librhsm-0.0.3-2.el7_6 docker-1.13.1-96.gitb2f74b2.el7 dpdk-18.11-4.el7_6 skopeo-0.1.35-2.git404c5bd.el7 containernetworking-plugins-0.7.5-2.el7 container-selinux-2.95-2.el7_6 buildah-1.7.1-2.git93747b1.el7 python-docker-py-1.10.6-9.el7_6 14.2.1. Container Images New : Red Hat Universal Base Image 7 Minimal Container Image (rhel7/ubi7-minimal) Red Hat Universal Base Image 7 Init Container Image (rhel7/ubi7-init) Updated : Red Hat Universal Base Image 7 Container Image (rhel7/ubi7) Red Hat Enterprise Linux 7.6 Container Image (rhel7.6, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux 7.6 Container Image for aarch64 (rhel7.6, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux Atomic Image (rhel-atomic, rhel7-atomic, rhel7/rhel-atomic) Red Hat Enterprise Linux 7 Init Container Image (rhel7/rhel7-init) Red Hat Enterprise Linux Atomic open-vm-tools Container Image (rhel7/open-vm-tools) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic Net-SNMP Container Image (rhel7/net-snmp) Red Hat Enterprise Linux Atomic cockpit-ws Container Image (rhel7/cockpit-ws) Red Hat Enterprise Linux Atomic flannel Container Image (rhel7/flannel) Red Hat Enterprise Linux Atomic etcd Container Image (rhel7/etcd) Red Hat Enterprise Linux Atomic Support Tools Container Image (rhel7/support-tools) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic Identity Management Server Container Image (rhel7/ipa-server) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) Red Hat Enterprise Linux Atomic OpenSCAP Container Image (rhel7/openscap) 14.3. New features Red Hat Universal Base Images (UBI) are now available With RHEL Atomic Host 7.6.4, Red Hat Universal Base Images (UBI) are newly available. For now, these UBIs are available: ubi7-init , ubi7-minimal , and ubi7 , which are intended to substitute the rhel7-init , rhel7-atomic , and rhel-server images. Additionally, a set of UBIs is now available that are intended to substitute some of the images currently provided through Red Hat Software Collections. Unlike older Red Hat images, UBIs are freely redistributable. This means they can be used in any environment and shared anywhere. You can use them even if you are not a Red Hat customer. For UBI documentation, see Using Red Hat Universal Base Images (standard, minimal, and runtimes) .

Commands:
Chapter 10. Automated installation workflow Kickstart installations can be performed using a local DVD, a local disk, or a NFS, FTP, HTTP, or HTTPS server. This section provides a high level overview of Kickstart usage. Create a Kickstart file. You can write it by hand, copy a Kickstart file saved after a manual installation, or use an online generator tool to create the file, and edit it afterward. Make the Kickstart file available to the installation program on removable media, a disk or a network location using an HTTP(S), FTP, or NFS server. Create the boot medium which will be used to begin the installation. Make the installation source available to the installation program. Start the installation using the boot medium and the Kickstart file. If the Kickstart file contains all mandatory commands and sections, the installation finishes automatically. If one or more of these mandatory parts are missing, or if an error occurs, the installation requires manual intervention to finish.

Commands:
Chapter 83. KafkaClientAuthenticationTls schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationTls schema properties To configure mTLS authentication, set the type property to the value tls . mTLS uses a TLS certificate to authenticate. The certificate is specified in the certificateAndKey property and is always loaded from an OpenShift secret. In the secret, the certificate must be stored in X509 format under two different keys: public and private. Example mTLS configuration authentication: type: tls certificateAndKey: secretName: my-secret certificate: my-public-tls-certificate-file.crt key: private.key You can use the secrets created by the User Operator, or you can create your own TLS certificate file, with the keys used for authentication, then create a Secret from the file: oc create secret generic <my_tls_secret> \ --from-file=<my_public_tls_certificate>.crt \ --from-file=<my_private_key>.key Example secret for mTLS client authentication apiVersion: v1 kind: Secret metadata: name: my-tls-secret type: Opaque data: tls.crt: LS0tLS1CRUdJTiBDRVJ... tls.key: LS0tLS1CRUdJTiBQUkl... Note mTLS authentication can only be used with TLS connections. 83.1. KafkaClientAuthenticationTls schema properties The type property is a discriminator that distinguishes use of the KafkaClientAuthenticationTls type from KafkaClientAuthenticationScramSha256 , KafkaClientAuthenticationScramSha512 , KafkaClientAuthenticationPlain , KafkaClientAuthenticationOAuth . It must have the value tls for the type KafkaClientAuthenticationTls . Property Property type Description type string Must be tls . certificateAndKey CertAndKeySecretSource Reference to the Secret which holds the certificate and private key pair.

Commands:
authentication: type: tls certificateAndKey: secretName: my-secret certificate: my-public-tls-certificate-file.crt key: private.key
create secret generic <my_tls_secret> --from-file=<my_public_tls_certificate>.crt --from-file=<my_private_key>.key
apiVersion: v1 kind: Secret metadata: name: my-tls-secret type: Opaque data: tls.crt: LS0tLS1CRUdJTiBDRVJ tls.key: LS0tLS1CRUdJTiBQUkl
3.15. Required Networks, Optional Networks, and Virtual Machine Networks A required network is a logical network that must be available to all hosts in a cluster. When a host's required network becomes non-operational, virtual machines running on that host are migrated to another host; the extent of this migration is dependent upon the chosen scheduling policy. This is beneficial if you have virtual machines running mission critical workloads. An optional network is a logical network that has not been explicitly declared as Required . Optional networks can be implemented on only the hosts that use them. The presence or absence of optional networks does not affect the Operational status of a host. When a non-required network becomes non-operational, the virtual machines running on the network are not migrated to another host. This prevents unnecessary I/O overload caused by mass migrations. Note that when a logical network is created and added to clusters, the Required box is selected by default. To change a network's Required designation, from the Administration Portal, select a network, click the Cluster tab, and click the Manage Networks button. A virtual machine network, called a VM network in the user interface, is a logical network designated to carry only virtual machine network traffic. A virtual machine network can be required or optional. Virtual machines that use an optional virtual machine network only start on hosts with that network.

Commands:
Network APIs OpenShift Container Platform 4.14 Reference guide for network APIs Red Hat OpenShift Documentation Team

Commands:
Name: "mysvc", Subsets: [ { Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }, { Addresses: [{"ip": "10.10.3.3"}], Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}] }, ]
Name: "mysvc", Subsets: [ { Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }, { Addresses: [{"ip": "10.10.3.3"}], Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}] }, ]
{ Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}], Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}] }
a: [ 10.10.1.1:8675, 10.10.2.2:8675 ], b: [ 10.10.1.1:309, 10.10.2.2:309 ]
4.286. sblim-smis-hba 4.286.1. RHBA-2011:1270 - sblim-smis-hba bug fix update An updated sblim-smis-hba package that fixes one bug is now available for Red Hat Enterprise Linux 6. The sblim-smis-hba package provides SMI-S standards based HBA CMPI Providers for CIMOM technology/infrastructure. Bug Fix BZ# 620422 Prior to this update, the sblim-smis-hba package's license field contained both the EPL and SNIA licenses, although no code in the package is licensed under the SNIA license. This bug has been fixed in this update by removing the SNIA license from the license field so that the field now contains the correct information. All users of sblim-smis-hba are advised to upgrade to this updated package, which fixes this bug.

Commands:
26.5. Loader Parameters The following parameters can be defined in a parameter file but do not work in a CMS configuration file. To automate the loader screens, specify the following parameters: lang= language Sets the language of the installer user interface, for example, en for English or de for German. This automates the response to Choose a Language (refer to Section 22.3, "Language Selection" ). repo= installation_source Sets the installation source to access stage 2 as well as the repository with the packages to be installed. This automates the response to Installation Method (refer to Section 22.4, "Installation Method" ).

Commands:
2.3. Threats to Server Security Server security is as important as network security because servers often hold a great deal of an organization's vital information. If a server is compromised, all of its contents may become available for the cracker to steal or manipulate at will. The following sections detail some of the main issues. 2.3.1. Unused Services and Open Ports A full installation of Red Hat Enterprise Linux contains 1000+ application and library packages. However, most server administrators do not opt to install every single package in the distribution, preferring instead to install a base installation of packages, including several server applications. A common occurrence among system administrators is to install the operating system without paying attention to what programs are actually being installed. This can be problematic because unneeded services may be installed, configured with the default settings, and possibly turned on. This can cause unwanted services, such as Telnet, DHCP, or DNS, to run on a server or workstation without the administrator realizing it, which in turn can cause unwanted traffic to the server, or even, a potential pathway into the system for crackers. Refer To Chapter 5, Server Security for information on closing ports and disabling unused services.

Commands:
3.3. Planning Guidelines The following are the guidelines for setting up Red Hat Gluster Storage on Microsoft Azure. Designate a management server for interaction and control with Microsoft Azure services. For simple Gluster Storage deployments (single site, single NIC), the management platform can be a Linux server/workstation. For more complex deployments, a Windows desktop with Powershell is recommended. Build custom images based on Red Hat Enterprise Linux 7 with the Hyper-V drivers included within the initramfs file. Instances will fail to start if these drivers are not present. Use a virtual network for your Red Hat Gluster Storage nodes. For geo-replication, deploy a common /etc/hosts file to all nodes or use a shared DNS server. Pricing for standard storage is based on used capacity. It therefore makes sense to use the maximum size for data disks (1023 GB) and allocate as many as the instance supports at install time to minimize future administration overheads. If NFS is the preferred way to connect to the Gluster Storage nodes, consider using a D series instance that has a more modern CPU with a higher clock speed. Use availability sets to group Gluster Storage nodes within a replication set together to enhance availability. Use mdadm to combine disks to form a larger disk. Use fewer, larger virtual machines to deliver the highest capacity. For highly available data access, use a replicated GlusterFS volume with the native glusterfs client. Use a non-default SSH port for public access to the SSH services running on each of the Gluster Storage nodes (that is, use --ssh with vm create ).

Commands:
7.3. Create a Private/Public Key Pair with Keytool Procedure 7.1. Create a Private/Public Key Pair with Keytool Run the keytool -genkey -alias ALIAS -keyalg ALGORITHM -validity DAYS -keystore server.keystore -storetype TYPE command: If the specified keystore already exists, enter the existing password for that keystore, otherwise enter a new password: Answer the following questions when prompted: Enter yes to confirm the provided information is correct: Enter your desired keystore password: Result The server.keystore file contains the newly generated public and private key pair.

Commands:
keytool -genkey -alias teiid -keyalg RSA -validity 365 -keystore server.keystore -storetype JKS
Enter keystore password: <password>
What is your first and last name? [Unknown]: <user's name> What is the name of your organizational unit? [Unknown]: <department name> What is the name of your organization? [Unknown]: <company name> What is the name of your City or Locality? [Unknown]: <city name> What is the name of your State or Province? [Unknown]: <state name> What is the two-letter country code for this unit? [Unknown]: <country name>
Is CN=<user's name>, OU=<department name>, O="<company name>", L=<city name>, ST=<state name>, C=<country name> correct? [no]: yes
Enter key password for <server> (Return if same as keystore password)
Chapter 1. Federal Information Processing Standard (FIPS) readiness and compliance The Federal Information Processing Standard (FIPS) developed by the National Institute of Standards and Technology (NIST) is regarded as the highly regarded for securing and encrypting sensitive data, notably in highly regulated areas such as banking, healthcare, and the public sector. Red Hat Enterprise Linux (RHEL) and OpenShift Container Platform support FIPS by providing a FIPS mode , in which the system only allows usage of specific FIPS-validated cryptographic modules like openssl . This ensures FIPS compliance. 1.1. Enabling FIPS compliance Use the following procedure to enable FIPS compliance on your Red Hat Quay deployment. Prerequisite If you are running a standalone deployment of Red Hat Quay, your Red Hat Enterprise Linux (RHEL) deployment is version 8 or later and FIPS-enabled. If you are deploying Red Hat Quay on OpenShift Container Platform, OpenShift Container Platform is version 4.10 or later. Your Red Hat Quay version is 3.5.0 or later. If you are using the Red Hat Quay on OpenShift Container Platform on an IBM Power or IBM Z cluster: OpenShift Container Platform version 4.14 or later is required Red Hat Quay version 3.10 or later is required You have administrative privileges for your Red Hat Quay deployment. Procedure In your Red Hat Quay config.yaml file, set the FEATURE_FIPS configuration field to true . For example: --- FEATURE_FIPS = true --- With FEATURE_FIPS set to true , Red Hat Quay runs using FIPS-compliant hash functions.

Commands:
--- FEATURE_FIPS = true ---
Appendix A. Using your subscription Streams for Apache Kafka is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Streams for Apache Kafka for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired Streams for Apache Kafka product. The Software Downloads page opens. Click the Download link for your component. Installing packages with DNF To install a package and all the package dependencies, use: dnf install <package_name> To install a previously-downloaded package from a local directory, use: dnf install <path_to_download_package> Revised on 2025-03-14 17:23:00 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
Chapter 7. OLM v1 (Technology Preview) 7.1. About Operator Lifecycle Manager v1 (Technology Preview) Important Operator Lifecycle Manager (OLM) v1 is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . Operator Lifecycle Manager (OLM) has been included with OpenShift Container Platform 4 since its initial release. OpenShift Container Platform 4.17 includes components for a -generation iteration of OLM as a Technology Preview feature, known during this phase as OLM v1 . This updated framework evolves many of the concepts that have been part of versions of OLM and adds new capabilities. Starting in OpenShift Container Platform 4.17, documentation for OLM v1 has been moved to the following new guide: Extensions (OLM v1)

Commands:
Chapter 7. Supported integration products AMQ Streams 1.7 supports integration with the following Red Hat products. Red Hat Single Sign-On 7.4 and later for OAuth 2.0 authentication and OAuth 2.0 authorization Red Hat Debezium 1.4 and later for monitoring databases and creating event streams For information on the functionality these products can introduce to your AMQ Streams deployment, refer to the AMQ Streams 1.7 documentation.

Commands: