mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Kafka Bridge interface The Kafka Bridge provides a RESTful interface that allows HTTP-based clients to interact with a Kafka cluster. It offers the advantages of a HTTP API connection to Streams for Apache Kafka for clients to produce and consume messages without the requirement to use the native Kafka protocol. The API has two main resources - consumers and topics - that are exposed and made accessible through endpoints to interact with consumers and producers in your Kafka cluster. The resources relate only to the Kafka Bridge, not the consumers and producers connected directly to Kafka. 5.1. HTTP requests The Kafka Bridge supports HTTP requests to a Kafka cluster, with methods to perform operations such as the following: Send messages to a topic. Retrieve messages from topics. Retrieve a list of partitions for a topic. Create and delete consumers. Subscribe consumers to topics, so that they start receiving messages from those topics. Retrieve a list of topics that a consumer is subscribed to. Unsubscribe consumers from topics. Assign partitions to consumers. Commit a list of consumer offsets. Seek on a partition, so that a consumer starts receiving messages from the first or last offset position, or a given offset position. The methods provide JSON responses and HTTP response code error handling. Messages can be sent in JSON or binary formats. Additional resources To view the API documentation, including example requests and responses, see Using the Streams for Apache Kafka Bridge . 5.2. Supported clients for the Kafka Bridge You can use the Kafka Bridge to integrate both internal and external HTTP client applications with your Kafka cluster. Internal clients Internal clients are container-based HTTP clients running in the same OpenShift cluster as the Kafka Bridge itself. Internal clients can access the Kafka Bridge on the host and port defined in the KafkaBridge custom resource. External clients External clients are HTTP clients running outside the OpenShift cluster in which the Kafka Bridge is deployed and running. External clients can access the Kafka Bridge through an OpenShift Route, a loadbalancer service, or using an Ingress. HTTP internal and external client integration

Commands:
Chapter 26. Exchange Property Overview The exchange property language provides a convenient way of accessing exchange properties . When you supply a key that matches one of the exchange property names, the exchange property language returns the corresponding value. The exchange property language is part of camel-core . XML example For example, to implement the recipient list pattern when the listOfEndpoints exchange property contains the recipient list, you could define a route as follows: Java example The same recipient list example can be implemented in Java as follows:

Commands:
<camelContext> <route> <from uri="direct:a"/> <recipientList> <exchangeProperty>listOfEndpoints</exchangeProperty> </recipientList> </route> </camelContext>
from("direct:a").recipientList(exchangeProperty("listOfEndpoints"));
5.2. Preparing to convert a physical machine Before you use P2V, you must first prepare your conversion server and download and prepare the rhel-6.x-p2v.iso boot media. For full instructions see the Red Hat Enterprise Linux Installation Guide . Note that there is one ISO image for both i386 and x86_64 architectures. 5.2.1. Install virt-v2v on a conversion server A conversion server is any physical server running Red Hat Enterprise Linux 6 or higher with the virt-v2v package installed on it. To install virt-v2v follow the instructions in Chapter 2, Installing virt-v2v . virt-v2v version 0.8.7-6 or higher is required.

Commands:
Chapter 15. Managing Packages You can use Satellite to install, upgrade, and remove packages on hosts. 15.1. Enabling and Disabling Repositories on Hosts Use this procedure to enable or disable repositories on hosts. Procedure In the Satellite web UI, navigate to Hosts > All Hosts , Select the host name. Click the Content tab. Click the Repository Sets tab. Click the vertical ellipsis. Choose Override to disabled or Override to enabled to disable or enable repositories on hosts. 15.2. Installing Packages on a Host Use this procedure to install packages on a host using the Satellite web UI. The list of packages available for installation depends on the Content View and Lifecycle Environment assigned to the host. Procedure In the Satellite web UI, navigate to Hosts > All Hosts . Select the host you want to install packages on. Select the Content tab, then select the Packages tab. Click the vertical ellipsis at the top of the page and select Install Packages . In the Install packages popup window, select the packages that you want to install on the host. Click Install . By default, the packages are installed using remote execution. 15.3. Upgrading Packages on a Host Use this procedure to upgrade packages on a host using the Satellite web UI. The packages are upgraded through Katello agent or remote execution, depending on your configuration. Procedure In the Satellite web UI, navigate to Hosts > All Hosts . Click the name of the host you want to modify. Select the Content tab, then select the Packages tab. Select the Upgradable filter from the Status box to list the upgradable packages. If a package has more than one available upgrade version, only the latest upgradable version is displayed. Click Upgrade . The remote execution job starts immediately. You can also customize the remote execution by selecting Upgrade via customized remote execution from the dropdown menu. 15.4. Removing Packages from a Host Use this procedure to remove packages from a host using the Satellite web UI. Procedure In the Satellite web UI, navigate to Hosts > All Hosts . Select the host you want to remove packages from. Select the Content tab, then select the Packages tab. Check the packages you want to remove. From the vertical ellipsis at the top, click Remove . You get a REX job notification once the packages are removed.

Commands:
Chapter 3. Registering the system for updates using GNOME You must register your system to get software updates for your system. This section explains how you can register your system using GNOME. Prerequisites A valid account with Red Hat customer portal See the Create a Red Hat Login page for new user registration. Activation Key or keys, if you are registering the system with activation key A registration server, if you are registering system using the registration server 3.1. Registering a system using an activation key on GNOME Follow the steps in this procedure to register your system with an activation key. You can get the activation key from your organization administrator. Prerequisites Activation key or keys. See the Activation Keys page for creating new activation keys. Procedure Open the system menu , which is accessible from the upper-right screen corner, and click Settings . Go to About Subscription . If you are not using the Red Hat server: In the Registration Server section, select Custom Address . Enter the server address in the URL field. In the Registration Type section, select Activation Keys . Under Registration Details : Enter your activation keys in the Activation Keys field. Separate your keys by a comma ( , ). Enter the name or ID of your organization in the Organization field. Click Register . 3.2. Unregistering the system using GNOME Follow the steps in this procedure to unregister your system. After unregistering, your system no longer receives software updates. Procedure Open the system menu , which is accessible from the upper-right screen corner, and click Settings . Go to About Subscription . The Registration Details screen appears. Click Unregister . A warning appears about the impact of unregistering the system. Click Unregister . 3.3. Additional resources Registering the system and managing subscriptions Creating Red Hat Customer Portal Activation Keys (Red Hat Knowledgebase) Creating and managing activation keys Registering Systems with Activation keys (Red Hat Knowledgebase)

Commands:
Cluster administration OpenShift Dedicated 4 Configuring OpenShift Dedicated clusters Red Hat OpenShift Documentation Team

Commands:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "*" } ] }
ocm create machine-pool --cluster <cluster_name|cluster_id> \ 1 --instance-type <instance_type> \ 2 --replicas <number_of_replicas> \ 3 --availability-zone <availability_zone> \ 4 [flags] \ 5 <machine_pool_id> 6
Appendix A. Using your subscription AMQ Streams 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 Red Hat AMQ Streams entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2021-08-18 09:24:31 UTC

Commands:
4.2. Model Classes and Types Teiid Designer can be used to model a variety of classes of models. Each of these represent a conceptually different classification of models. Relational - Model data that can be represented in table columns and records form. Relational models can represent structures found in relational databases, spreadsheets, text files, or simple Web services. XML - Model that represents the basic structures of XML documents. These can be backed by XML Schemas. XML models represent nested structures, including recursive hierarchies. XML Schema - W3C standard for formally defining the structure and constraints of XML documents, as well as the datatypes defining permissible values in XML documents. Web Services - which define Web service interfaces, operations, and operation input and output parameters (in the form of XML Schemas). Function - The Function metamodel supports the capability to provide user defined functions, including binary source jars, to use in custom transformation SQL statements.

Commands:
3.9. RHEA-2011:1731 - new package: perl-Test-Inter A new perl-Test-Inter package is now available for Red Hat Enterprise Linux 6. The Test::Inter module provides a framework for writing interactive test scripts in Perl. It is inspired by the Test::More framework. This enhancement update adds the perl-Test-Inter package to Red Hat Enterprise Linux 6. (BZ# 705752 ) All users who require perl-Test-Inter should install this new package.

Commands:
Chapter 3. GSettings and dconf One of the major changes in Red Hat Enterprise Linux 7 is the transition from GConf (for storing user preferences) to the combination of the GSettings high-level configuration system and the dconf back end. GConf As mentioned above, the GConf configuration system has been replaced by two systems: the GSettings API, and the dconf back end which serves as a low-level configuration system and program that collects system hardware and software configuration details in a single compact binary format. Both the gsettings command-line tool and the dconf utility are used to view and change user settings. The gsettings utility does so directly in the terminal, while the dconf utility uses the dconf-editor GUI for editing a configuration database. See Chapter 9, Configuring Desktop with GSettings and dconf for more information on dconf-editor and the gsettings utility. gconftool The gconftool-2 tool has been replaced by gsettings and dconf . Likewise, gconf-editor has been replaced by dconf-editor . Overriding The concept of keyfiles has been introduced in Red Hat Enterprise Linux 7: the dconf utility allows the system administrator to override the default settings by directly installing defaults overrides . For example, setting the default background for all users is now executed by using a dconf override placed in a keyfile in the keyfile directory, such as /etc/dconf/db/local.d/) . To learn more about default values and overriding, see Section 9.5, "Configuring Custom Default Values" . Locking the Settings The dconf system now allows individual settings or entire settings subpaths to be locked down to prevent user customization. For more information on how to lock settings, see Section 9.5.1, "Locking Down Specific Settings" . NFS and dconf Using the dconf utility on home directories shared over NFS requires additional configuration. See Section 9.7, "Storing User Settings Over NFS" for information on this topic. Getting More Information See Chapter 9, Configuring Desktop with GSettings and dconf for more information on using GSettings and dconf to configure user settings.

Commands:
7.28. corosync 7.28.1. RHBA-2015:1389 - corosync bug fix and enhancement update Updated corosync packages that fix one bug and add two enhancements are now available for Red Hat Enterprise Linux 6. The corosync packages provide the Corosync Cluster Engine and C Application Programming Interfaces (APIs) for Red Hat Enterprise Linux cluster software. Bug Fix BZ# 1136431 When the corosync utility was configured with the IPv6 network and packet fragmentation was disabled on the Network Interface Controller (NIC) or switch, no packets were delivered. This update implements a correct calculation of the data fragment size, and packets are delivered as intended. Enhancements BZ# 1163846 Earlier when using the UDP unicast (UDPU) protocol, all messages were sent to all the configured members, instead of being sent to only the active members. This makes sense for merge detection messages, otherwise it creates unnecessary traffic to missing members and can trigger excessive Address Resolution Protocol (ARP) requests on the network. The corosync code has been modified to only send messages to the missing members when it is required, otherwise to only send messages to the active ring members. Thus, most of the UDPU messages are now sent only to the active members with an exception of the messages required for proper detection of a merge or a new member (1-2 pkts/sec). BZ# 742999 With this update, the corosync packages have been modified to test whether the network interface has different IP address, port, and IP version when using the Redundant Ring Protocol (RRP) mode. Now, corosync properly checks correctness of the configuration file and prevents failures when using the RRP mode. Users of corosync are advised to upgrade to these updated packages, which fix this bug and add these enhancements.

Commands:
Chapter 1. Configuring Argo CD RBAC By default, if you are logged in to Argo CD using Red Hat SSO (RH SSO), you are a read-only user. You can change and manage the user level access. 1.1. Configuring user level access To manage and modify the user level access, configure the role-based access control (RBAC) section in the Argo CD custom resource (CR). Procedure Edit the argocd CR: USD oc edit argocd [argocd-instance-name] -n [namespace] Output metadata ... ... rbac: policy: 'g, rbacsystem:cluster-admins, role:admin' scopes: '[groups]' Add the policy configuration to the rbac section and add the name and the desired role to be applied to the user: metadata ... ... rbac: policy: g, <name>, role:<admin> scopes: '[groups]' Note Currently, RHSSO cannot read the group information of Red Hat OpenShift GitOps users. Therefore, configure the RBAC at the user level. 1.2. Modifying RHSSO resource requests/limits By default, the RHSSO container is created with resource requests and limitations. You can change and manage the resource requests. Resource Requests Limits CPU 500 1000m Memory 512 Mi 1024 Mi Procedure Modify the default resource requirements patching the Argo CD custom resource (CR): USD oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]' Note RHSSO created by the Red Hat OpenShift GitOps only persists the changes that are made by the operator. If the RHSSO restarts, any additional configuration created by the Admin in RHSSO is deleted.

Commands:
oc edit argocd [argocd-instance-name] -n [namespace]
metadata rbac: policy: 'g, rbacsystem:cluster-admins, role:admin' scopes: '[groups]'
metadata rbac: policy: g, <name>, role:<admin> scopes: '[groups]'
oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]'
Appendix B. The LVM Configuration Files LVM supports multiple configuration files. At system startup, the lvm.conf configuration file is loaded from the directory specified by the environment variable LVM_SYSTEM_DIR , which is set to /etc/lvm by default. The lvm.conf file can specify additional configuration files to load. Settings in later files override settings from earlier ones. To display the settings in use after loading all the configuration files, execute the lvmconfig command. For information on loading additional configuration files, see Section D.2, "Host Tags" . B.1. The LVM Configuration Files The following files are used for LVM configuration: /etc/lvm/lvm.conf Central configuration file read by the tools. etc/lvm/lvm_ hosttag .conf For each host tag, an extra configuration file is read if it exists: lvm_ hosttag .conf . If that file defines new tags, then further configuration files will be appended to the list of files to read in. For information on host tags, see Section D.2, "Host Tags" . In addition to the LVM configuration files, a system running LVM includes the following files that affect LVM system setup: /etc/lvm/cache/.cache Device name filter cache file (configurable). /etc/lvm/backup/ Directory for automatic volume group metadata backups (configurable). /etc/lvm/archive/ Directory for automatic volume group metadata archives (configurable with regard to directory path and archive history depth). /var/lock/lvm/ In single-host configuration, lock files to prevent parallel tool runs from corrupting the metadata; in a cluster, cluster-wide DLM is used.

Commands:
Chapter 1. Workflow and architecture To install Metrics Store, complete the following major tasks: Create the Metrics Store virtual machines . Deploy Metrics Store services on Red Hat OpenShift . Configure networking for Metrics Store virtual machines . Deploy collectd and rsyslog . Verify the Metrics Store installation . Metrics Store architecture The Metrics Store architecture is based on the Red Hat OpenShift EFK logging stack , running on Red Hat OpenShift Container Platform 3.11 . Metrics Store uses the following services: collectd (hosts) collects metrics from hosts, virtual machines, and databases. rsyslog (hosts) collects metrics, adds log data, enriches the data with metadata, and sends the enriched data to Elasticsearch. Elasticsearch (Metrics Store virtual machine) stores and indexes the data. Kibana (Metrics Store virtual machine) analyzes and presents the data as dashboards and charts. Figure 1.1. Metrics Store architecture

Commands:
Chapter 1. Introduction to Security in the Data Grid 1.1. Securing Data in Red Hat JBoss Data Grid In Red Hat JBoss Data Grid, data security can be implemented in the following ways: Role-based Access Control JBoss Data Grid features role-based access control for operations on designated secured caches. Roles can be assigned to users who access your application, with roles mapped to permissions for cache and cache-manager operations. Only authenticated users are able to perform the operations that are authorized for their role. In Library mode, data is secured via role-based access control for CacheManagers and Caches, with authentication delegated to the container or application. In Remote Client-Server mode, JBoss Data Grid is secured by passing identity tokens from the Hot Rod client to the server, and role-based access control of Caches and CacheManagers. Node Authentication and Authorization Node-level security requires new nodes or merging partitions to authenticate before joining a cluster. Only authenticated nodes that are authorized to join the cluster are permitted to do so. This provides data protection by preventing unauthorized servers from storing your data. Encrypted Communications Within the Cluster JBoss Data Grid increases data security by supporting encrypted communications between the nodes in a cluster by using a user-specified cryptography algorithm, as supported by Java Cryptography Architecture (JCA). JBoss Data Grid also provides audit logging for operations, and the ability to encrypt communication between the Hot Rod Client and Server using Transport Layer Security (TLS/SSL). Report a bug

Commands:
8.6. Multiple Caching Providers Caching providers are obtained from javax.cache.Caching using the overloaded getCachingProvider() method; by default this method will attempt to load any META-INF/services/javax.cache.spi.CachingProvider files found in the classpath. If one is found it will determine the caching provider in use. With multiple caching providers available a specific provider may be selected using either of the following methods: getCachingProvider(ClassLoader classLoader) getCachingProvider(String fullyQualifiedClassName) To switch between caching providers ensure that the appropriate provider is available in the default classpath, or select it using one of the above methods. All javax.cache.spi.CachingProviders that are detected or have been loaded by the Caching class are maintained in an internal registry, and subsequent requests for the same caching provider will be returned from this registry instead of being reloaded or reinstantiating the caching provider implementation. To view the current caching providers either of the following methods may be used: getCachingProviders() - provides a list of caching providers in the default class loader. getCachingProviders(ClassLoader classLoader) - provides a list of caching providers in the specified class loader. Report a bug

Commands:
12.8.4. Destroying the vHBA Storage Pool A vHBA storage pool can be destroyed by the virsh pool-destroy command: Delete the vHBA with the following command To verify the pool and vHBA have been destroyed, run: scsi_host5 will no longer appear in the list of results.

Commands:
virsh pool-destroy vhbapool_host3
virsh nodedev-destroy scsi_host5
virsh nodedev-list --cap scsi_host
3.5. Network Interface Controller The network interface controller (NIC) is a network adapter or LAN adapter that connects a computer to a computer network. The NIC operates on both the physical and data link layers of the machine and enables network connectivity. All virtualization hosts in a Red Hat Virtualization environment have at least one NIC, though it is more common for a host to have two or more NICs. One physical NIC can have multiple virtual NICs (vNICs) logically connected to it. A virtual NIC acts as a network interface for a virtual machine. To distinguish between a vNIC and the NIC that supports it, the Red Hat Virtualization Manager assigns each vNIC a unique MAC address.

Commands: