mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 74. KafkaClientAuthenticationScramSha256 schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationScramSha256 schema properties To configure SASL-based SCRAM-SHA-256 authentication, set the type property to scram-sha-256 . The SCRAM-SHA-256 authentication mechanism requires a username and password. 74.1. username Specify the username in the username property. 74.2. passwordSecret In the passwordSecret property, specify a link to a Secret containing the password. You can use the secrets created by the User Operator. If required, you can create a text file that contains the password, in cleartext, to use for authentication: echo -n PASSWORD > MY-PASSWORD .txt You can then create a Secret from the text file, setting your own field name (key) for the password: oc create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt Example Secret for SCRAM-SHA-256 client authentication for Kafka Connect apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm The secretName property contains the name of the Secret , and the password property contains the name of the key under which the password is stored inside the Secret . Important Do not specify the actual password in the password property. Example SASL-based SCRAM-SHA-256 client authentication configuration for Kafka Connect authentication: type: scram-sha-256 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field 74.3. KafkaClientAuthenticationScramSha256 schema properties Property Property type Description passwordSecret PasswordSecretSource Reference to the Secret which holds the password. type string Must be scram-sha-256 . username string Username used for the authentication.

Commands:
echo -n PASSWORD > MY-PASSWORD .txt
create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm
authentication: type: scram-sha-256 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field
Chapter 1. Preparing to install Red Hat OpenShift GitOps Read the following information about sizing requirements and prerequisites before you install Red Hat OpenShift GitOps on OpenShift Container Platform. Sizing requirements also provides the sizing details for the default ArgoCD instance that is instantiated by the Red Hat OpenShift GitOps Operator. 1.1. Sizing requirements for GitOps Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud-native applications. Through GitOps, you can define and configure the CPU and memory requirements of your application. Every time you install the Red Hat OpenShift GitOps Operator, the resources on the namespace are installed within the defined limits. If the default installation does not set any limits or requests, the Operator fails within the namespace with quotas. Without enough resources, the cluster cannot schedule ArgoCD related pods. The following table details the resource requests and limits for the default workloads: Workload CPU requests CPU limits Memory requests Memory limits argocd-application-controller 1 2 1024M 2048M applicationset-controller 1 2 512M 1024M argocd-server 0.125 0.5 128M 256M argocd-repo-server 0.5 1 256M 1024M argocd-redis 0.25 0.5 128M 256M argocd-dex 0.25 0.5 128M 256M HAProxy 0.25 0.5 128M 256M Optionally, you can also use the ArgoCD custom resource with the oc command to see the specifics and modify them: oc edit argocd <name of argo cd> -n namespace

Commands:
edit argocd <name of argo cd> -n namespace
Chapter 3. Configuring IP Networking As a system administrator, you can configure a network interface either using NetworkManager or not. 3.1. Selecting Network Configuration Methods To configure a network interface using NetworkManager , use one of the following tools: the text user interface tool, nmtui . For more details, see Section 3.2, "Configuring IP Networking with nmtui" . the command-line tool, nmcli . For more details, see Section 3.3, "Configuring IP Networking with nmcli" . the graphical user interface tools, GNOME GUI . For more details, see Section 3.4, " Configuring IP Networking with GNOME GUI " . To configure a network interface without using NetworkManager : edit the ifcfg files manually. For more details, see Section 3.5, "Configuring IP Networking with ifcfg Files" . use the ip commands. This can be used to assign IP addresses to an interface, but changes are not persistent across reboots; when you reboot, you will lose any changes. For more details, see Section 3.6, "Configuring IP Networking with ip Commands" . To configure the network settings when the root filesystem is not local: use the kernel command-line. For more details, see Section 3.7, "Configuring IP Networking from the Kernel Command line" .

Commands:
Chapter 10. Troubleshooting scrub and deep-scrub issues Learn to troubleshoot the scrub and deep-scrub issues. 10.1. Addressing the scrub slowness issue while upgrading to 8 Learn to troubleshoot the scrub slowness issue which seen after upgrading to Red Hat Ceph Storage 8. Scrub slowness is caused by the automated OSD benchmark setting a very low value for osd_mclock_max_capacity_iops_hdd . Due to this, scrub operations are impacted since the IOPS capacity of an OSD plays a significant role in determining the bandwidth the scrub operation receives. To further increase the problem, scrubs receive only a fraction of the total IOPS capacity based on the QoS allocation defined by the mClock profile. Due to this, the Ceph cluster reports the expected scrub completion time in multiples of days or weeks. Prequisites A running Red Hat Ceph Storage cluster in a healthy state. Root-level access to the node. Procedure Detect low measured IOPS reported by OSD bench during OSD boot-up and fallback to default IOPS setting defined for osd_mclock_max_capacity_iops_[hdd|ssd] . The fallback is triggered if the reported IOPS falls below a threshold determined by osd_mclock_iops_capacity_low_threshold_[hdd|ssd] . A cluster warning is also logged. Example: [Optional]: Perform the following steps: For clusters already affected by the issue, remove the IOPS capacity setting on the OSD(s) before upgrading to the release with the fix by running the following command: Example: Set the osd_mclock_force_run_benchmark_on_init option for the affected OSD to true before the upgrade: Example: After upgrading to the release with this fix, the IOPS capacity reflects the default setting or the new one reported by the OSD bench. [Optional]: Perform the following steps if you have already upgraded from 7 to 8 (after upgrade): If you were unable to perform the above steps before upgrade, you re-run the OSD bench again after upgrading by removing the osd_mclock_max_capacity_iops_[hdd|ssd] setting: Example: Set osd_mclock_force_run_benchmark_on_init to true . Example: Restart the OSD. After the OSD restarts, the IOPS capacity reflects the default setting or the new setting reported by the OSD bench.

Commands:
ceph config rm osd.X osd_mclock_max_capacity_iops_[hdd|ssd]
ceph config rm osd.X osd_mclock_max_capacity_iops_[hdd|ssd]
ceph config set osd.X osd_mclock_force_run_benchmark_on_init true
ceph config rm osd.X osd_mclock_max_capacity_iops_[hdd|ssd]
ceph config set osd.X osd_mclock_force_run_benchmark_on_init true
28.7. Renaming a Server or Replica Host System There is no way to change the hostname for an IdM server or replica machine. The Kerberos keys and certificate management is too complex to allow the hostname to change. Rather, if a server or replica needs to be renamed, it is easier to replace the instance. Create a new replica, with a CA, with the new hostname or IP address. This is described in Chapter 4, Setting up IdM Replicas . Stop the original IdM server instance. Verify that all other servers/replicas and clients are working as before. Uninstall the IdM server, as in Chapter 7, Uninstalling IdM Servers and Replicas

Commands:
ipactl stop
3.5. Setting Cgroup Parameters Modify the parameters of the control groups by editing the /etc/cgconfig.conf configuration file, or by using the cgset command. Changes made to /etc/cgconfig.conf are preserved after reboot, while cgset changes the cgroup parameters only for the current session. Modifying /etc/cgconfig.conf You can set the controller parameters in the Groups section of /etc/cgconfig.conf . Group entries are defined using the following syntax: Replace name with the name of your cgroup, controller stands for the name of the controller you wish to modify. You should modify only controllers you mounted yourself, not any of the default controllers mounted automatically by systemd . Replace param_name and param_value with the controller parameter you wish to change and its new value. Note that the permissions section is optional. To define permissions for a group entry, use the following syntax: Note Restart the cgconfig service for the changes in the /etc/cgconfig.conf to take effect. Restarting this service rebuilds hierarchies specified in the configuration file but does not affect all mounted hierarchies. You can restart a service by executing the systemctl restart command, however, it is recommended to first stop the cgconfig service: Then open and edit the configuration file. After saving your changes, you can start cgconfig again with the following command: Using the cgset Command Set controller parameters by running the cgset command from a user account with permission to modify the relevant cgroup. Use this only for controllers you mounted manually. The syntax for cgset is: where: parameter is the parameter to be set, which corresponds to the file in the directory of the given cgroup; value is the value for the parameter; path_to_cgroup is the path to the cgroup relative to the root of the hierarchy . The values that can be set with cgset might depend on values set higher in a particular hierarchy. For example, if group1 is limited to use only CPU 0 on a system, you cannot set group1/subgroup1 to use CPUs 0 and 1, or to use only CPU 1. It is also possible use cgset to copy the parameters of one cgroup into another, existing cgroup. The syntax to copy parameters with cgset is: where: path_to_source_cgroup is the path to the cgroup whose parameters are to be copied, relative to the root group of the hierarchy; path_to_target_cgroup is the path to the destination cgroup, relative to the root group of the hierarchy.

Commands:
group name { [ permissions ] controller { param_name = param_value ; ... } ... }
perm { task { uid = task_user ; gid = task_group ; } admin { uid = admin_name ; gid = admin_group ; } }
~]# systemctl stop cgconfig
~]# systemctl start cgconfig
cgset -r parameter = value path_to_cgroup
cgset --copy-from path_to_source_cgroup path_to_target_cgroup
Chapter 1. Preparing to deploy OpenShift Data Foundation Deploying OpenShift Data Foundation on OpenShift Container Platform using dynamic storage devices provides you with the option to create internal cluster resources. This will result in the internal provisioning of the base services, which helps to make additional storage classes available to applications. Before you begin the deployment of OpenShift Data Foundation, follow these steps: Setup a chrony server. See Configuring chrony time service and use knowledgebase solution to create rules allowing all traffic. Optional: If you want to enable cluster-wide encryption using the external Key Management System (KMS) HashiCorp Vault, follow these steps: Ensure that you have a valid Red Hat OpenShift Data Foundation Advanced subscription. To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions . When the Token authentication method is selected for encryption then refer to Enabling cluster-wide encryption with the Token authentication using KMS . When the Kubernetes authentication method is selected for encryption then refer to Enabling cluster-wide encryption with the Kubernetes authentication using KMS . Ensure that you are using signed certificates on your Vault servers. Note If you are using Thales CipherTrust Manager as your KMS, you will enable it during deployment. Minimum starting node requirements An OpenShift Data Foundation cluster is deployed with minimum configuration when the standard deployment resource requirement is not met. See Resource requirements section in Planning guide. Disaster recovery requirements Disaster Recovery features supported by Red Hat OpenShift Data Foundation require all of the following prerequisites to successfully implement a disaster recovery solution: A valid Red Hat OpenShift Data Foundation Advanced subscription A valid Red Hat Advanced Cluster Management for Kubernetes subscription To know how subscriptions for OpenShift Data Foundation work, see knowledgebase article on OpenShift Data Foundation subscriptions . For detailed requirements, see Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads guide, and Requirements and recommendations section of the Install guide in Red Hat Advanced Cluster Management for Kubernetes documentation.

Commands:
Chapter 81. ExternalConfiguration schema reference Used in: KafkaConnectSpec , KafkaMirrorMaker2Spec Full list of ExternalConfiguration schema properties Configures external storage properties that define configuration options for Kafka Connect connectors. You can mount ConfigMaps or Secrets into a Kafka Connect pod as environment variables or volumes. Volumes and environment variables are configured in the externalConfiguration property in KafkaConnect.spec or KafkaMirrorMaker2.spec . When applied, the environment variables and volumes are available for use when developing your connectors. For more information, see Loading configuration values from external sources . 81.1. ExternalConfiguration schema properties Property Description env Makes data from a Secret or ConfigMap available in the Kafka Connect pods as environment variables. ExternalConfigurationEnv array volumes Makes data from a Secret or ConfigMap available in the Kafka Connect pods as volumes. ExternalConfigurationVolumeSource array

Commands:
E.4. Using the sysctl Command The /sbin/sysctl command is used to view, set, and automate kernel settings in the /proc/sys/ directory. For a quick overview of all settings configurable in the /proc/sys/ directory, type the /sbin/sysctl -a command as root. This creates a large, comprehensive list, a small portion of which looks something like the following: This is the same information seen if each of the files were viewed individually. The only difference is the file location. For example, the /proc/sys/net/ipv4/route/min_pmtu file is listed as net.ipv4.route.min_pmtu , with the directory slashes replaced by dots and the proc.sys portion assumed. The sysctl command can be used in place of echo to assign values to writable files in the /proc/sys/ directory. For example, instead of using the command use the equivalent sysctl command as follows: While quickly setting single values like this in /proc/sys/ is helpful during testing, this method does not work as well on a production system as special settings within /proc/sys/ are lost when the machine is rebooted. To preserve custom settings, add them to the /etc/sysctl.conf file. The /etc/sysctl.conf file is installed by the initscripts package to override some kernel default values and therefore only contains a few of the possible parameters. Use the sysctl -a command to list the parameters in the sysctl key format. See the /usr/share/doc/kernel-doc- kernel_version /Documentation/networking/ip-sysctl.txt file for more information on the possible settings. Each time the system boots, the init program runs the /etc/rc.d/rc.sysinit script. This script contains a command to execute sysctl using /etc/sysctl.conf to determine the values passed to the kernel. Any values added to /etc/sysctl.conf therefore take effect each time the system boots. Note that modules loaded after sysctl has parsed this file might override the settings.

Commands:
net.ipv4.route.min_pmtu = 552 kernel.sysrq = 0 kernel.sem = 250 32000 32 128
echo 1 > /proc/sys/kernel/sysrq
sysctl -w kernel.sysrq="1" kernel.sysrq = 1
probe::ipmib.InNoRoutes Name probe::ipmib.InNoRoutes - Count an arriving packet with no matching socket Synopsis ipmib.InNoRoutes Values op value to be added to the counter (default value of 1) skb pointer to the struct sk_buff being acted on Description The packet pointed to by skb is filtered by the function ipmib_filter_key . If the packet passes the filter is is counted in the global InNoRoutes (equivalent to SNMP's MIB IPSTATS_MIB_INNOROUTES)

Commands:
Chapter 63. KafkaExporterSpec schema reference Used in: KafkaSpec Property Property type Description image string The container image used for the Kafka Exporter pods. If no image name is explicitly specified, the image name corresponds to the version specified in the Cluster Operator configuration. If an image name is not defined in the Cluster Operator configuration, a default value is used. groupRegex string Regular expression to specify which consumer groups to collect. Default value is .* . topicRegex string Regular expression to specify which topics to collect. Default value is .* . groupExcludeRegex string Regular expression to specify which consumer groups to exclude. topicExcludeRegex string Regular expression to specify which topics to exclude. resources ResourceRequirements CPU and memory resources to reserve. logging string Only log messages with the given severity or above. Valid levels: [ info , debug , trace ]. Default log level is info . enableSaramaLogging boolean Enable Sarama logging, a Go client library used by the Kafka Exporter. showAllOffsets boolean Whether show the offset/lag for all consumer group, otherwise, only show connected consumer groups. template KafkaExporterTemplate Customization of deployment templates and pods. livenessProbe Probe Pod liveness check. readinessProbe Probe Pod readiness check.

Commands:
27.3. Configuring PKINIT in IdM If your IdM servers are running with PKINIT disabled, use these steps to enable it. For example, a server is running with PKINIT disabled if you passed the --no-pkinit option with the ipa-server-install or ipa-replica-install utilities. Prerequisites Ensure that all IdM servers with a certificate authority (CA) installed are running on the same domain level. See Chapter 7, Displaying and Raising the Domain Level for details. Procedure Check if PKINIT is enabled on the server: If PKINIT is disabled, you will see the following output: You can also use the command to find all the servers where PKINIT is enabled if you omit the --server <server_fqdn> parameter. If you are using IdM without CA: On the IdM server, install the CA certificate that signed the Kerberos key distribution center (KDC) certificate: To update all IPA hosts, repeat the ipa-certupdate command on all replicas and clients: Check if the CA certificate has already been added using the ipa-cacert-manage list command. For example: Use the ipa-server-certinstall utility to install an external KDC certificate. The KDC certificate must meet the following conditions: It is issued with the common name CN= fully_qualified_domain_name , certificate_subject_base . It includes the Kerberos principal krbtgt/ REALM_NAME @ REALM_NAME . It contains the Object Identifier (OID) for KDC authentication: 1.3.6.1.5.2.3.5 . See your PKINIT status: If you are using IdM with a CA certificate, enable PKINIT as follows: If you are using an IdM CA, the command requests a PKINIT KDC certificate from the CA. Additional Resources For more information, see ipa-server-certinstall(1) man page.

Commands:
kinit admin Password for admin@IPA.TEST: ipa pkinit-status --server=server.idm.example.com ---------------- 1 server matched ---------------- Server name: server.idm.example.com PKINIT status: enabled ---------------------------- Number of entries returned 1 ----------------------------
ipa pkinit-status --server server.idm.example.com ----------------- 0 servers matched ----------------- ---------------------------- Number of entries returned 0 ----------------------------
ipa-cacert-manage install -t CT,C,C ca.pem
ipa-certupdate
ipa-cacert-manage list CN=CA,O=Example Organization The ipa-cacert-manage command was successful
ipa-server-certinstall --kdc kdc.pem kdc.key systemctl restart krb5kdc.service
ipa pkinit-status Server name: server1.example.com PKINIT status: enabled [...output truncated...] Server name: server2.example.com PKINIT status: disabled [...output truncated...]
ipa-pkinit-manage enable Configuring Kerberos KDC (krb5kdc) [1/1]: installing X509 Certificate for PKINIT Done configuring Kerberos KDC (krb5kdc). The ipa-pkinit-manage command was successful
Chapter 11. Subscribing functions to CloudEvents You can subscribe a function to a set of events. This links your function to CloudEvent objects defined by your filters and enables automated responses. 11.1. Subscribing a function to CloudEvents The subscribe command connects the function to a set of events, matching a series of filters for CloudEvent metadata and a Knative Broker as the source of events, from where they are consumed. Prerequisites You have installed Knative Eventing on the cluster. You have configured a Knative Broker. You have installed the Knative ( kn ) CLI. Procedure Subscribe the function to events for a given broker by running the following command: Example command USD kn func subscribe --filter type=com.example.Hello --source my-broker Use the --source flag to specify the broker and one or more --filter flags to specify your filters. You can also omit the --source flag to use the default broker: Example command USD kn func subscribe --filter type=com.example --filter extension=my-extension-value Deploy the function with Knative Triggers: Example command USD kn func deploy Example output 🙌 Function image built: <registry>/hello:latest 🎯 Creating Triggers on the cluster ✅ Function deployed in namespace "default" and exposed at URL: http://hello.default.my-cluster.example.com

Commands:
kn func subscribe --filter type=com.example.Hello --source my-broker
kn func subscribe --filter type=com.example --filter extension=my-extension-value
kn func deploy
🙌 Function image built: <registry>/hello:latest 🎯 Creating Triggers on the cluster ✅ Function deployed in namespace "default" and exposed at URL: http://hello.default.my-cluster.example.com
5.3.9.2. /proc/sys/fs/ This directory contains an array of options and information concerning various aspects of the file system, including quota, file handle, inode, and dentry information. The binfmt_misc/ directory is used to provide kernel support for miscellaneous binary formats. The important files in /proc/sys/fs/ include: dentry-state - Provides the status of the directory cache. The file looks similar to the following: The first number reveals the total number of directory cache entries, while the second number displays the number of unused entries. The third number tells the number of seconds between when a directory has been freed and when it can be reclaimed, and the fourth measures the pages currently requested by the system. The last two numbers are not used and display only zeros. dquot-nr - Lists the maximum number of cached disk quota entries. file-max - Lists the maximum number of file handles that the kernel allocates. Raising the value in this file can resolve errors caused by a lack of available file handles. file-nr - Lists the number of allocated file handles, used file handles, and the maximum number of file handles. overflowgid and overflowuid - Defines the fixed group ID and user ID, respectively, for use with file systems that only support 16-bit group and user IDs. super-max - Controls the maximum number of superblocks available. super-nr - Displays the current number of superblocks in use.

Commands:
57411 52939 45 0 0 0