mtpti5iD/redhat-docs_dataset huggingface dataset:
Architecture Red Hat OpenShift Service on AWS 4 Architecture overview. Red Hat OpenShift Documentation Team

Commands:
apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration 1 metadata: name: <webhook_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: default 5 name: kubernetes 6 path: <webhook_url> 7 caBundle: <ca_signing_certificate> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11 sideEffects: None
apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration 1 metadata: name: <webhook_name> 2 webhooks: - name: <webhook_name> 3 clientConfig: 4 service: namespace: default 5 name: kubernetes 6 path: <webhook_url> 7 caBundle: <ca_signing_certificate> 8 rules: 9 - operations: 10 - <operation> apiGroups: - "" apiVersions: - "*" resources: - <resource> failurePolicy: <policy> 11 sideEffects: Unknown
Chapter 3. Customizing the Fuse Console branding You can customize the Fuse Console branding information, such as title, logo, and login page information, by adding a hawtconfig.json file into your Fuse on Spring Boot standalone application. Procedure Create a JSON file named hawtconfig.json in your local Fuse on Spring Boot standalone application's src/main/webapp directory. Open the src/main/webapp/hawtconfig.json in an editor of your choice, and then add the following content: Change the values of the configuration properties listed in Table A.1, "Fuse Console Configuration Properties" . Save your changes. Run Fuse on Spring Boot by using the following command: In a web browser, open the Fuse Console by using this URL: http://localhost:10001/actuator/hawtio/index.html Note If you have already run the Fuse Console in a web browser, the branding is stored in the browser's local storage. To use new branding settings, you must clear the browser's local storage.

Commands:
{ "branding": { "appName": "Red Hat Fuse Console", "appLogoUrl": "img/Logo-Red_Hat-Fuse-A-Reverse-RGB.png", "companyLogoUrl": "img/Logo-RedHat-A-Reverse-RGB.png" }, "login": { "description": "", "links": [] }, "about": { "title": "Red Hat Fuse Console", "productInfo": [], "additionalInfo": "", "copyright": "", "imgSrc": "img/Logo-RedHat-A-Reverse-RGB.png" }, "disabledRoutes": [ "/camel/source", "/diagnostics", "/jvm/discover", "/jvm/local" ] }
mvn spring-boot:run
20.16. Discarding Blocks Not in Use The virsh domfstrim domain [--minimum bytes ] [--mountpoint mountPoint ] command invokes the fstrim utility on all mounted file systems within a specified running guest virtual machine. This discards blocks not in use by the file system. If the argument --minimum is used, an amount in bytes must be specified. This amount will be sent to the guest kernel as its length of contiguous free range. Values smaller than this amount may be ignored. Increasing this value will create competition with file systems with badly fragmented free space. Note that not all blocks in this case are discarded. The default minimum is zero which means that every free block is discarded. If you increase this value to greater than zero, the fstrim operation will complete more quickly for file systems with badly fragmented free space, although not all blocks will be discarded. If a user only wants to trim one specific mount point, the --mountpoint argument should be used and a mount point should be specified. Example 20.38. How to discard blocks not in use The following example trims the file system running on the guest virtual machine named guest1 : # virsh domfstrim guest1 --minimum 0

Commands:
Chapter 9. Hosts Table 9.1. Hosts Subcommand Description and tasks hostgroup org loc Create a host group: Add an activation key to a host group: host org loc Create a host (inheriting parameters from a host group): job-template Add a job template for remote execution: job-invocation Invoke a remote job: Monitor the remote job:

Commands:
hammer hostgroup create --name hg_name --puppet-environment env_name --architecture arch_name --domain domain_name --subnet subnet_name --puppet-proxy proxy_name --puppet-ca-proxy ca-proxy_name --operatingsystem os_name --partition-table table_name --medium medium_name --organization-ids org_ID1,... --location-ids loc_ID1,
hammer hostgroup set-parameter --hostgroup "hg_name" --name "kt_activation_keys" --value key_name
hammer host create --name host_name --hostgroup hg_name --interface="primary=true, mac= mac_addr , ip= ip_addr , provision=true" --organization-id org_ID --location-id loc_ID --ask-root-password yes
hammer job-template create --file path --name template_name --provider-type SSH --job-category category_name
hammer job-invocation create --job-template template_name --inputs key1= value,... --search-query query
hammer job-invocation output --id job_id --host host_name
5.4.3.3. Repairing a Mirrored Logical Device You can use the lvconvert --repair command to repair a mirror after a disk failure. This brings the mirror back into a consistent state. The lvconvert --repair command is an interactive command that prompts you to indicate whether you want the system to attempt to replace any failed devices. To skip the prompts and replace all of the failed devices, specify the -y option on the command line. To skip the prompts and replace none of the failed devices, specify the -f option on the command line. To skip the prompts and still indicate different replacement policies for the mirror image and the mirror log, you can specify the --use-policies argument to use the device replacement policies specified by the mirror_log_fault_policy and mirror_device_fault_policy parameters in the lvm.conf file.

Commands:
Chapter 10. Managing Geo-replication This section introduces geo-replication, illustrates the various deployment scenarios, and explains how to configure geo-replication and mirroring. 10.1. About Geo-replication Geo-replication provides a distributed, continuous, asynchronous, and incremental replication service from one site to another over Local Area Networks (LANs), Wide Area Networks (WANs), and the Internet. Geo-replication uses a master-slave model, where replication and mirroring occurs between the following partners: Master - the primary Red Hat Gluster Storage volume. Slave - a secondary Red Hat Gluster Storage volume. A slave volume can be a volume on a remote host, such as remote-host::volname .

Commands:
Chapter 1. Introduction The Red Hat OpenStack Platform director provides a set of tools to provision and create a fully featured OpenStack environment, also known as the Overcloud. The Director Installation and Usage Guide covers the preparation and configuration of the Overcloud. However, a proper production-level Overcloud might require additional configuration, including: Basic network configuration to integrate the Overcloud into your existing network infrastructure. Network traffic isolation on separate VLANs for certain OpenStack network traffic types. SSL configuration to secure communication on public endpoints Storage options such as NFS, iSCSI, Red Hat Ceph Storage, and multiple third-party storage devices. Registration of nodes to the Red Hat Content Delivery Network or your internal Red Hat Satellite 5 or 6 server. Various system-level options. Various OpenStack service options. This guide provides instructions for augmenting your Overcloud through the director. At this point, the director has registered the nodes and configured the necessary services for Overcloud creation. Now you can customize your Overcloud using the methods in this guide. Note The examples in this guide are optional steps for configuring the Overcloud. These steps are only required to provide the Overcloud with additional functionality. Use the steps that apply to the needs of your environment.

Commands:
Chapter 6. Fixed issues The following sections list the issues fixed in AMQ Streams 1.8.x. Red Hat recommends that you upgrade to the latest patch release For details of the issues fixed in Kafka 2.8.0, refer to the Kafka 2.8.0 Release Notes . 6.1. Fixed issues for AMQ Streams 1.8.4 The AMQ Streams 1.8.4 patch release is now available. The AMQ Streams product images have been upgraded to version 1.8.4. For additional details about the issues resolved in AMQ Streams 1.8.4, see AMQ Streams 1.8.x Resolved Issues . Log4j2 vulnerability The 1.8.4 release fixes a remote code execution vulnerability for AMQ Streams components that use log4j2. The vulnerability could allow a remote code execution on the server if the system logs a string value from an unauthorized source. This affects log4j versions between 2.0 and 2.14.1. For more information, see CVE-2021-44228 . 6.2. Fixed issues for AMQ Streams 1.8.0 Issue Number Description ENTMQST-1529 FileStreamSourceConnector stops when using a large file. ENTMQST-2359 Kafka Bridge does not handle assignment and subscription. ENTMQST-2453 The kafka-exporter pod restarts for no reason. ENTMQST-2459 Running Kafka Exporter leads to high CPU usage. ENTMQST-2511 Fine tune the health checks to stop Kafka Exporter restarting during rolling updates. ENTMQST-2777 ENTMQST-2777 Custom Bridge labels are not set when the service template is not specified. ENTMQST-2974 Changing the log level for Kafka Connect connectors only works temporarily. Table 6.1. Fixed common vulnerabilities and exposures (CVEs) Issue Number Description ENTMQST-1934 CVE-2020-9488 log4j: improper validation of certificate with host mismatch in SMTP appender [amq-st-1]. ENTMQST-2613 CVE-2020-13949 libthrift: potential DoS when processing untrusted payloads [amq-st-1]. ENTMQST-2617 CVE-2021-21290 netty: Information disclosure via the local system temporary directory [amq-st-1]. ENTMQST-2647 CVE-2021-21295 netty: possible request smuggling in HTTP/2 due missing validation [amq-st-1]. ENTMQST-2663 CVE-2021-27568 json-smart: uncaught exception may lead to crash or information disclosure [amq-st-1]. ENTMQST-2711 ENTMQST-2711 CVE-2021-21409 netty: Request smuggling via content-length header [amq-st-1]. ENTMQST-2821 CVE-2021-28168 jersey-common: jersey: Local information disclosure via system temporary directory [amq-st-1]. ENTMQST-2867 CVE-2021-29425 commons-io: apache-commons-io: Limited path traversal in Apache Commons IO 2.2 to 2.6 [amq-st-1]. ENTMQST-2908 ENTMQST-2908 CVE-2021-28165 jetty-server: jetty: Resource exhaustion when receiving an invalid large TLS frame [amq-st-1]. ENTMQST-2909 CVE-2021-28164 jetty-server: jetty: Ambiguous paths can access WEB-INF [amq-st-1]. ENTMQST-2910 CVE-2021-28163 jetty-server: jetty: Symlink directory exposes webapp directory contents [amq-st-1]. ENTMQST-2980 CVE-2021-28169 jetty-server: jetty: requests to the ConcatServlet and WelcomeFilter are able to access protected resources within the WEB-INF directory [amq-st-1]. ENTMQST-3023 CVE-2021-34428 jetty-server: jetty: SessionListener can prevent a session from being invalidated breaking logout [amq-st-1].

Commands:
Chapter 2. Features Streams for Apache Kafka 2.7 introduces the features described in this section. Streams for Apache Kafka 2.7 on RHEL is based on Apache Kafka 3.7.0. Note To view all the enhancements and bugs that are resolved in this release, see the Streams for Apache Kafka Jira project . 2.1. Kafka 3.7.0 support Streams for Apache Kafka now supports and uses Apache Kafka version 3.7.0. Only Kafka distributions built by Red Hat are supported. For upgrade instructions, see the instructions for Streams for Apache Kafka and Kafka upgrades in the following guides: Using Streams for Apache Kafka on RHEL in KRaft mode Using Streams for Apache Kafka on RHEL with ZooKeeper Refer to the Kafka 3.7.0 Release Notes for additional information. Kafka 3.6.x is supported only for the purpose of upgrading to Streams for Apache Kafka 2.7. We recommend that you perform a rolling update to use the new binaries. Note Kafka 3.7.0 provides access to KRaft mode, where Kafka runs without ZooKeeper by utilizing the Raft protocol. 2.2. KRaft: Support for migrating from ZooKeeper-based to KRaft-based Kafka clusters KRaft mode in Streams for Apache Kafka is a technology preview , with some limitations, but this release introduces a number of new features that support KRaft. To support using KRaft, a new using guide is available: Using Streams for Apache Kafka on RHEL in KRaft mode . If you are using ZooKeeper for metadata management in your Kafka cluster, you can now migrate to using Kafka in KRaft mode. During the migration, you do the following: Install a quorum of controller nodes, which replaces ZooKeeper for management of your cluster. Enable KRaft migration in the controller configuration by setting the zookeeper.metadata.migration.enable flag to true . Enable KRaft migration in the brokers by setting the zookeeper.metadata.migration.enable flag to true . Switch the brokers to using KRaft by adding a broker KRaft role and node ID. Switch the controllers out of migration mode by removing the zookeeper.metadata.migration.enable property. See Migrating to KRaft mode . 2.3. KRaft: Kafka upgrades for the KRaft-based clusters KRaft to KRaft upgrades are now supported. You update the installation files, then configure and restart all Kafka nodes. You then upgrade the KRaft-based Kafka cluster to a newer supported KRaft metadata version. Updating the KRaft metadata version ./bin/kafka-features.sh --bootstrap-server <broker_host>:<port> upgrade --metadata 3.7 See Upgrading KRaft-based Kafka clusters . 2.4. RHEL 7 no longer supported RHEL 7 is no longer supported. The decision was made due to known incompatibility issues .

Commands:
./bin/kafka-features.sh --bootstrap-server <broker_host>:<port> upgrade --metadata 3.7
20.6. Memory Backing Memory backing allows the hypervisor to properly manage large pages within the guest virtual machine. The optional <memoryBacking> element may have an <hugepages> element set within it. This tells the hypervisor that the guest virtual machine should have its memory allocated using hugepages instead of the normal native page size. <domain> ... <memoryBacking> <hugepages/> </memoryBacking> ... </domain> Figure 20.8. Memory backing

Commands:
<domain> <memoryBacking> <hugepages/> </memoryBacking> </domain>
Chapter 2. sVirt sVirt is a technology included in Red Hat Enterprise Linux 6 that integrates SELinux and virtualization. sVirt applies Mandatory Access Control (MAC) to improve security when using guest virtual machines. This integrated technology improves security and hardens the system against bugs in the hypervisor. It is particularly helpful in preventing attacks on the host physical machine or on another guest virtual machine. This chapter describes how sVirt integrates with virtualization technologies in Red Hat Enterprise Linux 6. Non-virtualized Environments In a non-virtualized environment, host physical machines are separated from each other physically and each host physical machine has a self-contained environment, consisting of services such as a web server, or a DNS server. These services communicate directly to their own user space, host physical machine's kernel and physical hardware, offering their services directly to the network. The following image represents a non-virtualized environment: User Space - memory area where all user mode applications and some drivers execute. Web App (web application server) - delivers web content that can be accessed through the a browser. Host Kernel - is strictly reserved for running the host physical machine's privileged kernel, kernel extensions, and most device drivers. DNS Server - stores DNS records allowing users to access web pages using logical names instead of IP addresses. Virtualized Environments In a virtualized environment, several virtual operating systems can run on a single kernel residing on a host physical machine. The following image represents a virtualized environment: 2.1. Security and Virtualization When services are not virtualized, machines are physically separated. Any exploit is usually contained to the affected machine, with the obvious exception of network attacks. When services are grouped together in a virtualized environment, extra vulnerabilities emerge in the system. If there is a security flaw in the hypervisor that can be exploited by a guest virtual machine, this guest virtual machine may be able to not only attack the host physical machine, but also other guest virtual machines running on that host physical machine. These attacks can extend beyond the guest virtual machine and could expose other guest virtual machines to an attack as well. sVirt is an effort to isolate guest virtual machines and limit their ability to launch further attacks if exploited. This is demonstrated in the following image, where an attack cannot break out of the guest virtual machine and invade other guest virtual machines: SELinux introduces a pluggable security framework for virtualized instances in its implementation of Mandatory Access Control (MAC). The sVirt framework allows guest virtual machines and their resources to be uniquely labeled. Once labeled, rules can be applied which can reject access between different guest virtual machines.

Commands:
Chapter 5. Additional resources 5.1. Tag specifications by integration type Tagging standards differ between integration types. To use the same tags/labels across integrations, you must use the most common of all the restrictions across the different providers. The following table summarizes tagging and labelling criteria across AWS, Azure and OpenShift Container Platform 4: Table 5.1. Tagging specifications by integration Criteria AWS Azure Google Cloud Red Hat OpenShift Name Tags Tags Labels Labels Format Key & value Name & value Key & value Key & value Keys: [prefix/]name Prefix: must be a DNS subdomain Allows empty value Yes Yes Yes Yes Unique label per key Yes Yes Yes Yes Case sensitive Yes No Only lowercase letters Yes Limit per resource 50 50 (15 for storage) 64 N/A Length of key 128 512 (128 for storage) 63 253(prefix) / 63(name) Length of value 256 256 63 63 Allowed characters Letters, numbers, and spaces representable in UTF-8, and the following characters: + - = . _ : / @ Tag names cannot contain these characters: <, >, %, &, \, ?, / Only lowercase letters, numeric characters, underscores, and dashes. The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between Restrictions The prefix "aws:" is reserved. Tags applied to EC2 can use any character. Not all resource types support tags. Not all resource types support tags. Generalized VMs do not support tags. Tags applied to the resource group are not inherited by the resources. Keys must start with a lowercase letter or international character. Prefixes kubernetes.io/ and k8s.io/ are reserved. Not all resource types support tags. Notes You need to select the tag keys that will be included in cost and usage files and billing reports. You can use a JSON string to go over the limit of keys. There is no limit on how many labels you can apply across all resources within a project. If the prefix is omitted, the label Key is presumed to be private to the user. 5.2. Further reading The following links provide further guidance on tagging for each integration type. AWS: AWS tagging strategies IAM: Add a specific tag with specific values OpenShift: Kubernetes labels and selectors Kubernetes user guide: labels Microsoft Azure: Azure resource naming and tagging decision guide Azure recommended naming and tagging conventions Use tags to organize your Azure resources and management hierarchy Enforce tags in Azure resource groups Google Cloud: Creating and managing labels

Commands:
Chapter 1. Cloud integrations on the Hybrid Cloud Console You can integrate some public clouds and third-party applications with the Hybrid Cloud Console. For information about integrating third-party applications to receive event notifications, see Integrating the Red Hat Hybrid Cloud Console with third-party applications . A cloud integration on the Red Hat Hybrid Cloud Console is an association with a public cloud service, application, or provider that supplies data to a Hybrid Cloud Console service. Services on the Hybrid Cloud Console use the integrations service to connect with public cloud providers and other services or tools to collect information for the service. You can integrate the following public clouds with the Hybrid Cloud Console: Amazon Web Services (AWS) Microsoft Azure Google Cloud Oracle Cloud You can also connect your Red Hat OpenShift Container Platform environment to the Hybrid Cloud Console as a cloud integration to use with the cost management service on the console. You can add and manage cloud and Red Hat integrations from the Integrations* page, located in the Hybrid Cloud Console Settings menu. The Integrations service uses a wizard to help you connect cloud and Red Hat integrations to the Hybrid Cloud Console. For cloud integrations, you can associate the provider with Red Hat services, including cost management, launch images, and the Red Hat Enterprise Linux (RHEL) management bundle. For Red Hat integrations, you can add Red Hat OpenShift Container Platform. Associating a service is optional for cloud integrations, but is required for Red Hat integrations.

Commands:
5.147. libexif 5.147.1. RHSA-2012:1255 - Moderate: libexif security update Updated libexif packages that fix multiple security issues are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The libexif packages provide an Exchangeable image file format (Exif) library. Exif allows metadata to be added to and read from certain types of image files. Security Fix CVE-2012-2812 , CVE-2012-2813 , CVE-2012-2814 , CVE-2012-2836 , CVE-2012-2837 , CVE-2012-2840 , CVE-2012-2841 Multiple flaws were found in the way libexif processed Exif tags. An attacker could create a specially-crafted image file that, when opened in an application linked against libexif, could cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. Red Hat would like to thank Dan Fandrich for reporting these issues. Upstream acknowledges Mateusz Jurczyk of the Google Security Team as the original reporter of CVE-2012-2812, CVE-2012-2813, and CVE-2012-2814; and Yunho Kim as the original reporter of CVE-2012-2836 and CVE-2012-2837. Users of libexif are advised to upgrade to these updated packages, which contain backported patches to resolve these issues. All running applications linked against libexif must be restarted for the update to take effect.

Commands: