mtpti5iD/redhat-docs_dataset huggingface dataset:
6.4. RHEA-2015:1418 - new packages: python-requests and dependencies A new python-requests package and its dependencies, python-chardet, python-urllib3, python-six, python-backports, and python-backports-ssl_match_hostname, are now available for Red Hat Enterprise Linux 6. The python-requests package contains a library designed to make HTTP requests easy for developers. This enhancement update adds the python-requests package and its dependencies to Red Hat Enterprise Linux 6. The following packages are now available from the base channels in Red Hat Network: python-requests, python-chardet, python-urllib3, python-six, python-backports, and python-backports-ssl_match_hostname. (BZ# 1176248 , BZ# 1176251 , BZ# 1176257 , BZ# 1176258 , BZ# 1183141 , BZ# 1183146 ) All users who require python-requests, python-chardet, python-urllib3, python-six, python-backports, and python-backports-ssl_match_hostname are advised to install these new packages.

Commands:
19.6. Setting Account Lockout Policies A brute force attack occurs when a malefactor attempts to guess a password by simply slamming the server with multiple login attempts. An account lockout policy prevents brute force attacks by blocking an account from logging into the system after a certain number of login failures - even if the correct password is subsequently entered. Note A user account can be manually unlocked by an administrator using the ipa user-unlock . Refer to Section 9.6, "Unlocking User Accounts After Password Failures" . 19.6.1. In the UI These attributes are available in the password policy form when a group-level password policy is created or when any password policy (including the global password policy) is edited. Click the Policy tab, and then click the Password Policies subtab. Click the name of the policy to edit. Set the account lockout attribute values. There are three parts to the account lockout policy: The number of failed login attempts before the account is locked ( Max Failures ). The time after a failed login attempt before the counter resets ( Failure reset interval ). Since mistakes do happen honestly, the count of failed attempts is not kept forever; it naturally lapses after a certain amount of time. This is in seconds. How long an account is locked after the max number of failures is reached ( Lockout duration ). This is in seconds. 19.6.2. In the CLI There are three parts to the account lockout policy: The number of failed login attempts before the account is locked ( --maxfail ). How long an account is locked after the max number of failures is reached ( --lockouttime ). This is in seconds. The time after a failed login attempt before the counter resets ( --failinterval ). Since mistakes do happen honestly, the count of failed attempts is not kept forever; it naturally lapses after a certain amount of time. This is in seconds. These account lockout attributes can all be set when a password policy is created with pwpolicy-add or added later using pwpolicy-mod . For example:

Commands:
[jsmith@ipaserver ~]USD kinit admin [jsmith@ipaserver ~]USD ipa pwpolicy-mod examplegroup --maxfail=4 --lockouttime=600 --failinterval=30
Chapter 2. Additional release notes Release notes for additional related components and products not included in the core OpenShift Container Platform 4.18 release notes are available in the following documentation. Important The following release notes are for downstream Red Hat products only; upstream or community release notes for related products are not included. A AWS Load Balancer Operator B Builds for Red Hat OpenShift C cert-manager Operator for Red Hat OpenShift Cluster Observability Operator (COO) Compliance Operator Custom Metrics Autoscaler Operator D Red Hat Developer Hub Operator E External DNS Operator F File Integrity Operator K Kube Descheduler Operator L Logging M Migration Toolkit for Containers (MTC) N Network Observability Operator Network-bound Disk Encryption (NBDE) Tang Server Operator O OpenShift API for Data Protection (OADP) Red Hat OpenShift Dev Spaces Red Hat OpenShift distributed tracing platform Red Hat OpenShift GitOps Red Hat OpenShift Local (Upstream CRC documentation) Red Hat OpenShift Pipelines OpenShift sandboxed containers Red Hat OpenShift Serverless Red Hat OpenShift Service Mesh 2.x Red Hat OpenShift Service Mesh 3.x Red Hat OpenShift support for Windows Containers Red Hat OpenShift Virtualization Red Hat build of OpenTelemetry P Power monitoring for Red Hat OpenShift R Run Once Duration Override Operator S Secondary Scheduler Operator for Red Hat OpenShift Security Profiles Operator

Commands:
Chapter 2. Required custom resource upgrades Debezium is a Kafka connector plugin that is deployed to an Apache Kafka cluster that runs on AMQ Streams on OpenShift. To prepare for OpenShift CRD v1 , in the current version of AMQ Streams the required version of the custom resource definitions (CRD) API is now set to v1beta2 . The v1beta2 version of the API replaces the previously supported v1beta1 and v1alpha1 API versions. Support for the v1alpha1 and v1beta1 API versions is now deprecated in AMQ Streams. Those earlier versions are now removed from most AMQ Streams custom resources, including the KafkaConnect and KafkaConnector resources that you use to configure Debezium connectors. The CRDs that are based on the v1beta2 API version use the OpenAPI structural schema. Custom resources based on the superseded v1alpha1 or v1beta1 APIs do not support structural schemas, and are incompatible with the current version of AMQ Streams. Before you upgrade to AMQ Streams2.5, you must upgrade existing custom resources to use API version kafka.strimzi.io/v1beta2 . You can upgrade custom resources any time after you upgrade to AMQ Streams 1.7. You must complete the upgrade to the v1beta2 API before you upgrade to AMQ Streams2.5 or newer. To facilitate the upgrade of CRDs and custom resources, AMQ Streams provides an API conversion tool that automatically upgrades them to a format that is compatible with v1beta2 . For more information about the tool and for the complete instructions about how to upgrade AMQ Streams, see Deploying and Upgrading AMQ Streams on OpenShift . Note The requirement to update custom resources applies only to Debezium deployments that run on AMQ Streams on OpenShift. The requirement does not apply to Debezium on Red Hat Enterprise Linux

Commands:
5.6. Other ext4 File System Utilities Red Hat Enterprise Linux 7 also features other utilities for managing ext4 file systems: e2fsck Used to repair an ext4 file system. This tool checks and repairs an ext4 file system more efficiently than ext3, thanks to updates in the ext4 disk structure. e2label Changes the label on an ext4 file system. This tool also works on ext2 and ext3 file systems. quota Controls and reports on disk space (blocks) and file (inode) usage by users and groups on an ext4 file system. For more information on using quota , refer to man quota and Section 17.1, "Configuring Disk Quotas" . fsfreeze To suspend access to a file system, use the command # fsfreeze -f mount-point to freeze it and # fsfreeze -u mount-point to unfreeze it. This halts access to the file system and creates a stable image on disk. Note It is unnecessary to use fsfreeze for device-mapper drives. For more information see the fsfreeze(8) manpage. As demonstrated in Section 5.2, "Mounting an ext4 File System" , the tune2fs utility can also adjust configurable file system parameters for ext2, ext3, and ext4 file systems. In addition, the following tools are also useful in debugging and analyzing ext4 file systems: debugfs Debugs ext2, ext3, or ext4 file systems. e2image Saves critical ext2, ext3, or ext4 file system metadata to a file. For more information about these utilities, refer to their respective man pages.

Commands:
Chapter 5. Installation Troubleshoot issues with your installation. 5.1. Issue - Cannot locate certain packages that come bundled with the Ansible Automation Platform installer You cannot locate certain packages that come bundled with the Ansible Automation Platform installer, or you are seeing a "Repositories disabled by configuration" message. To resolve this issue, enable the repository by using the subscription-manager command in the command line. For more information about resolving this issue, see the Troubleshooting section of Attaching your Red Hat Ansible Automation Platform subscription in Access management and authentication .

Commands:
Chapter 5. What to do ? Day 2 As a storage administrator, once you have installed and configured Red Hat Ceph Storage 7, you are ready to perform "Day Two" operations for your storage cluster. These operations include adding metadata servers (MDS) and object gateways (RGW), and configuring services such as NFS. For more information about how to use the cephadm orchestrator to perform "Day Two" operations, refer to the Red Hat Ceph Storage 7 Operations Guide . To deploy, configure, and administer the Ceph Object Gateway on "Day Two" operations, refer to the Red Hat Ceph Storage 7 Object Gateway Guide .

Commands:
22.3. GNOME Boxes Boxes is a lightweight graphical desktop virtualization tool used to view and access virtual machines and remote systems. Unlike virt-viewer and remote-viewer , Boxes allows viewing guest virtual machines, but also creating and configuring them, similar to virt-manager . However, in comparison with virt-manager , Boxes offers fewer management options and features, but is easier to use. To install Boxes , run: Open Boxes through Applications ⇒ System Tools . The main screen shows the available guest virtual machines. The right side of the screen has two buttons: - the search button, to search for guest virtual machines by name, and - the selection button. Clicking the selection button allows you to select one or more guest virtual machines in order to perform operations individually or as a group. The available operations are shown at the bottom of the screen on the operations bar: Figure 22.3. The Operations Bar There are four operations that can be performed: Favorite : Adds a heart to selected guest virtual machines and moves them to the top of the list of guests. This becomes increasingly helpful as the number of guests grows. Pause : The selected guest virtual machines will stop running. Delete : Removes selected guest virtual machines. Properties : Shows the properties of the selected guest virtual machine. Create new guest virtual machines using the New button on the left side of the main screen. Procedure 22.1. Creating a new guest virtual machine with Boxes Click New This opens the Introduction screen. Click Continue . Figure 22.4. Introduction screen Select source The Source Selection screen has three options: Available media: Any immediately available installation media will be shown here. Clicking any of these will take you directly to the Review screen. Enter a URL : Type in a URL to specify a local URI or path to an ISO file. This can also be used to access a remote machine. The address should follow the pattern of protocol :// IPaddress ? port ; , for example: The protocols can be spice:// , qemu:// , or vnc:// Select a file : Open a file directory to search for installation media manually. Figure 22.5. Source Selection screen Review the details The Review screen shows the details of the guest virtual machine. Figure 22.6. Review screen These details can be left as is, in which case proceed to the final step, or: Optional: customize the details clicking Customize allows you to adjust the configuration of the guest virtual machine, such as the memory and disk size. Figure 22.7. Customization screen Create Click Create . The new guest virtual machine will open.

Commands:
yum install gnome-boxes
spice://192.168.122.1?port=5906;
5.7. Securing Sendmail Sendmail is a Mail Transport Agent (MTA) that uses the Simple Mail Transport Protocol (SMTP) to deliver electronic messages between other MTAs and to email clients or delivery agents. Although many MTAs are capable of encrypting traffic between one another, most do not, so sending email over any public networks is considered an inherently insecure form of communication. For more information about how email works and an overview of common configuration settings, refer to the chapter titled Email in the Reference Guide . This section assumes a basic knowledge of how to generate a valid /etc/mail/sendmail.cf by editing the /etc/mail/sendmail.mc and running the m4 command as explained in the Reference Guide . It is recommended that anyone planning to implement a Sendmail server address the following issues. 5.7.1. Limiting a Denial of Service Attack Because of the nature of email, a determined attacker can flood the server with mail fairly easily and cause a denial of service. By setting limits to the following directives in /etc/mail/sendmail.mc , the effectiveness of such attacks are limited. confCONNECTION_RATE_THROTTLE - The number of connections the server can receive per second. By default, Sendmail does not limit the number of connections. If a limit is set and reached, further connections are delayed. confMAX_DAEMON_CHILDREN - The maximum number of child processes that can be spawned by the server. By default, Sendmail does not assign a limit to the number of child processes. If a limit is set and reached, further connections are delayed. confMIN_FREE_BLOCKS - The minimum number of free blocks which must be available for the server to accept mail. The default is 100 blocks. confMAX_HEADERS_LENGTH - The maximum acceptable size (in bytes) for a message header. confMAX_MESSAGE_SIZE - The maximum acceptable size (in bytes) for any one message.

Commands:
Chapter 130. KafkaBridgeProducerSpec schema reference Used in: KafkaBridgeSpec Full list of KafkaBridgeProducerSpec schema properties Configures producer options for the Kafka Bridge as keys. The values can be one of the following JSON types: String Number Boolean Exceptions You can specify and configure the options listed in the Apache Kafka configuration documentation for producers . However, Streams for Apache Kafka takes care of configuring and managing options related to the following, which cannot be changed: Kafka cluster bootstrap address Security (encryption, authentication, and authorization) Consumer group identifier Properties with the following prefixes cannot be set: bootstrap.servers sasl. security. ssl. If the config property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file. All other supported options are forwarded to Kafka Bridge, including the following exceptions to the options configured by Streams for Apache Kafka: Any ssl configuration for supported TLS versions and cipher suites Example Kafka Bridge producer configuration apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # ... producer: config: acks: 1 delivery.timeout.ms: 300000 # ... Important The Cluster Operator does not validate keys or values in the config object. If an invalid configuration is provided, the Kafka Bridge deployment might not start or might become unstable. In this case, fix the configuration so that the Cluster Operator can roll out the new configuration to all Kafka Bridge nodes. 130.1. KafkaBridgeProducerSpec schema properties Property Property type Description config map The Kafka producer configuration used for producer instances created by the bridge. Properties with the following prefixes cannot be set: ssl., bootstrap.servers, sasl., security. (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols).

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # producer: config: acks: 1 delivery.timeout.ms: 300000 #
9.5. Caching Considerations Although, you can find information about all JBoss Data Virtualization settings using the Management CLI (see Section 10.1, "JBoss Data Virtualization Settings" ), this section provides some additional information about those settings related to caching. JBoss Data Virtualization settings regarding cache tuning are divided amongst: Resultset Cache Tuning Prepared Plan Cache Tuning Cache statistics can be obtained through the Management Console or AdminShell. The statistics can be used to help tune cache parameters and ensure a hit ratio. Plans are currently fully held in memory and may have a significant memory footprint. When making extensive use of prepared statements and/or virtual procedures, the size of the plan cache may be increased proportionally to number of gigabytes intended for use by JBoss Data Virtualization. While the result cache parameters control the cache result entries (such as max number, and eviction), the result batches themselves are accessed through the buffer manager. If the size of the result cache is increased, you may need to tune the buffer manager configuration to ensure there is enough buffer space. Result set and prepared plan caches have their entries invalidated by data and metadata events. By default, these events are captured by running commands through JBoss Data Virtualization (see the Red Hat JBoss Data Virtualization Developer Guide for further customization). JBoss Data Virtualization stores compiled forms of update plans or trigger actions with the prepared plan so that if metadata changes, the changes may take effect immediately. The default resultset-cache-max-staleness for resultset caching is 60 seconds to improve efficiency with rapidly changing sources. Consider decreasing this value to make the resultset cache more consistent with the underlying data. Even with a setting of 0, full transactional consistency is not guaranteed. Warning Disabling or constraining these caches will lead to poor performance.

Commands:
26.2. DM Multipath DM Multipath is a feature that allows you to configure multiple I/O paths between server nodes and storage arrays into a single device. These I/O paths are physical SAN connections that can include separate cables, switches, and controllers. Multipathing aggregates the I/O paths, creating a new device that consists of the aggregated paths. DM Multipath are used primarily for the following reasons: Redundancy DM Multipath can provide failover in an active/passive configuration. In an active/passive configuration, only half the paths are used at any time for I/O. If any element of an I/O path fails, DM Multipath switches to an alternate path. Improved Performance DM Multipath can be configured in active/active mode, where I/O is spread over the paths in a round-robin fashion. In some configurations, DM Multipath can detect loading on the I/O paths and dynamically rebalance the load. For more information, see the Red Hat DM Multipath guide.

Commands:
Chapter 4. Managing build output Use the following sections for an overview of and instructions for managing build output. 4.1. Build output Builds that use the source-to-image (S2I) strategy result in the creation of a new container image. The image is then pushed to the container image registry specified in the output section of the Build specification. If the output kind is ImageStreamTag , then the image will be pushed to the integrated OpenShift image registry and tagged in the specified imagestream. If the output is of type DockerImage , then the name of the output reference will be used as a docker push specification. The specification may contain a registry or will default to DockerHub if no registry is specified. If the output section of the build specification is empty, then the image will not be pushed at the end of the build. Output to an ImageStreamTag spec: output: to: kind: "ImageStreamTag" name: "sample-image:latest" Output to a docker Push Specification spec: output: to: kind: "DockerImage" name: "my-registry.mycompany.com:5000/myimages/myimage:tag" 4.2. Output image environment variables source-to-image (S2I) strategy builds set the following environment variables on output images: Variable Description OPENSHIFT_BUILD_NAME Name of the build OPENSHIFT_BUILD_NAMESPACE Namespace of the build OPENSHIFT_BUILD_SOURCE The source URL of the build OPENSHIFT_BUILD_REFERENCE The Git reference used in the build OPENSHIFT_BUILD_COMMIT Source commit used in the build Additionally, any user-defined environment variable, for example those configured with S2I strategy options, will also be part of the output image environment variable list. 4.3. Output image labels source-to-image (S2I) builds set the following labels on output images: Label Description io.openshift.build.commit.author Author of the source commit used in the build io.openshift.build.commit.date Date of the source commit used in the build io.openshift.build.commit.id Hash of the source commit used in the build io.openshift.build.commit.message Message of the source commit used in the build io.openshift.build.commit.ref Branch or reference specified in the source io.openshift.build.source-location Source URL for the build You can also use the BuildConfig.spec.output.imageLabels field to specify a list of custom labels that will be applied to each image built from the build configuration. Custom labels for built images spec: output: to: kind: "ImageStreamTag" name: "my-image:latest" imageLabels: - name: "vendor" value: "MyCompany" - name: "authoritative-source-url" value: "registry.mycompany.com"

Commands:
spec: output: to: kind: "ImageStreamTag" name: "sample-image:latest"
spec: output: to: kind: "DockerImage" name: "my-registry.mycompany.com:5000/myimages/myimage:tag"
spec: output: to: kind: "ImageStreamTag" name: "my-image:latest" imageLabels: - name: "vendor" value: "MyCompany" - name: "authoritative-source-url" value: "registry.mycompany.com"
Chapter 52. EntityOperatorTemplate schema reference Used in: EntityOperatorSpec Property Property type Description deployment DeploymentTemplate Template for Entity Operator Deployment . pod PodTemplate Template for Entity Operator Pods . topicOperatorContainer ContainerTemplate Template for the Entity Topic Operator container. userOperatorContainer ContainerTemplate Template for the Entity User Operator container. tlsSidecarContainer ContainerTemplate Template for the Entity Operator TLS sidecar container. serviceAccount ResourceTemplate Template for the Entity Operator service account. entityOperatorRole ResourceTemplate Template for the Entity Operator Role. topicOperatorRoleBinding ResourceTemplate Template for the Entity Topic Operator RoleBinding. userOperatorRoleBinding ResourceTemplate Template for the Entity Topic Operator RoleBinding.

Commands:
Chapter 22. General Updates Addition of CtrlAltDelBurstAction for Systemd The systemd response to multiple CTRL+ALT+DEL events is now configurable by setting the CtrlAltDelBurstAction option in /etc/systemd/system.conf (BZ#1353028) cgred can now resolve rules concerning NSS users and groups Previously, the cgred service was not configured to start up after services providing Name Service Switch (NSS) users and groups. Also, information about skipping invalid rules was shown only in debug mode. Consequently, rules in the cgrules.conf file concerning NSS users and groups were sometimes ignored without any log message. With this update, cgred is configured to start after the nss-user-lookup target and level of log messages about skipping rules is changed to warning, which is also set as a default log level for the cgred daemon. As a result, NSS users and groups are now always resolved before starting cgred . Also, the warning message is logged in case some rules in cgrules.conf are invalid. (BZ#1406927)

Commands: