mtpti5iD/redhat-docs_dataset huggingface dataset:
8.7. Selecting Interfaces to Use as Ports for a Network Team To view the available interfaces, issue the following command: From the available interfaces, determine which are suitable for adding to your network team and then proceed to Section 8.8, "Selecting Network Team Configuration Methods"

Commands:
~]USD ip link show 1: lo: <LOOPBACK,UP,LOWER_UP > mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP > mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 52:54:00:6a:02:8a brd ff:ff:ff:ff:ff:ff 3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP > mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 52:54:00:9b:6d:2a brd ff:ff:ff:ff:ff:ff
Deploying and managing OpenShift Data Foundation using Red Hat OpenStack Platform Red Hat OpenShift Data Foundation 4.16 Instructions on deploying and managing OpenShift Data Foundation on Red Hat OpenStack Platform Red Hat Storage Documentation Team Abstract Read this document for instructions about how to install and manage Red Hat OpenShift Data Foundation using Red Hat OpenShift Container Platform on Red Hat OpenStack Platform (RHOSP). Important Deploying and managing OpenShift Data Foundation on Red Hat OpenStack Platform is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Commands:
Chapter 3. Breaking changes This section lists breaking changes with Red Hat Developer Hub 1.2: 3.1. Guest authentication must now be explicitly enabled In versions of Red Hat Developer Hub, guest authentication was enabled by default. As of Developer Hub 1.2, guest authentication is disabled by default and needs to be explicitly enabled for use. The guest login is provided by a special authentication provider that must be explicitly enabled. This authentication provider should be used for development purposes only and is not intended for production , as it creates a default user that has user-level access to the Developer Hub instance. You can enable the guest authentication provider in your app-config-rhdh ConfigMap as follows: auth: providers: guest: dangerouslyAllowOutsideDevelopment: true 3.2. Improved validation permission policies from different sources In this release, Developer Hub provides more strict validation on the source of permission policies and roles based on how you define the first role. This update improves the validation of the different sources of permission policies and roles and provides more consistent policy definition. If a permission policy or role with a new member does not match the originating role's source, Developer Hub prevents any update to permissions. Sources include 'REST, 'CSV', 'Configuration', and 'legacy'. Before updating your Red Hat Developer Hub application, you should migrate all permission policies and roles to a single source based on their respective roles. This can be done by using the GET roles endpoint to review the source information and by querying the role-metadata table of the permission database. You can make updates to permission policies by using one of the following: REST API, CSV file, and the database.

Commands:
auth: providers: guest: dangerouslyAllowOutsideDevelopment: true
probe::nfs.proc.read Name probe::nfs.proc.read - NFS client synchronously reads file from server Synopsis nfs.proc.read Values offset the file offset server_ip IP address of server flags used to set task->tk_flags in rpc_init_task function prot transfer protocol count read bytes in this execution version NFS version Description All the nfs.proc.read kernel functions were removed in kernel commit 8e0969 in December 2006, so these probes do not exist on Linux 2.6.21 and newer kernels.

Commands:
Chapter 3. Technology Previews Important Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete; therefore, Red Hat does not recommend implementing any Technology Preview features in production environments. This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope . 3.1. Kafka Static Quota plugin configuration Use the Kafka Static Quota plugin to set throughput and storage limits on brokers in your Kafka cluster. You can set a byte-rate threshold and storage quotas to put limits on the clients interacting with your brokers. Example Kafka Static Quota plugin configuration client.quota.callback.class= io.strimzi.kafka.quotas.StaticQuotaCallback client.quota.callback.static.produce= 1000000 client.quota.callback.static.fetch= 1000000 client.quota.callback.static.storage.soft= 400000000000 client.quota.callback.static.storage.hard= 500000000000 client.quota.callback.static.storage.check-interval= 5 See Setting limits on brokers using the Kafka Static Quota plugin . 3.2. Cruise Control for cluster rebalancing You can install Cruise Control and use it to rebalance your Kafka cluster using optimization goals - defined constraints on CPU, disk, network load, and more. In a balanced Kafka cluster, the workload is more evenly distributed across the broker pods. Cruise Control helps to reduce the time and effort involved in running an efficient and balanced Kafka cluster. A zipped distribution of Cruise Control is available for download from the AMQ Streams software downloads page . To install Cruise Control, you configure each Kafka broker to use the provided Metrics Reporter. Then, you set Cruise Control properties, including optimization goals, and start Cruise Control using the provided script. The Cruise Control server is hosted on a single machine for the whole Kafka cluster. When Cruise Control is running, you can use the REST API to: Generate dry run optimization proposals from multiple optimization goals Initiate an optimization proposal to rebalance the Kafka cluster Other Cruise Control features are not currently supported, including notifications, write-your-own goals, and changing the topic replication factor. See Cruise Control for cluster rebalancing .

Commands:
client.quota.callback.class= io.strimzi.kafka.quotas.StaticQuotaCallback client.quota.callback.static.produce= 1000000 client.quota.callback.static.fetch= 1000000 client.quota.callback.static.storage.soft= 400000000000 client.quota.callback.static.storage.hard= 500000000000 client.quota.callback.static.storage.check-interval= 5
probe::ioscheduler_trace.elv_requeue_request Name probe::ioscheduler_trace.elv_requeue_request - Fires when a request is Synopsis Values disk_major Disk major no of request. rq Address of request. name Name of the probe point elevator_name The type of I/O elevator currently enabled. disk_minor Disk minor number of request. rq_flags Request flags. Description put back on the queue, when the hadware cannot accept more requests.

Commands:
ioscheduler_trace.elv_requeue_request
Chapter 1. Overview of the Cryostat dashboard The Cryostat Dashboard provides a high-level overview of the target Java Virtual Machines (JVMs) that are connected to Cryostat and helps you to identify and resolve performance issues, review system efficiency, and determine how to optimize application performance. By using the dashboard, you can view performance data for your JDK Flight Recorder (JFR) recordings and important information and metrics about your target JVMs. The dashboard displays static and dynamic information about your connected JVMs through a variety of dashboard cards, which you can organize and customize in different layouts, according to your requirements. You access the dashboard directly from the navigation menu of the Cryostat console by clicking Dashboard .

Commands:
Chapter 1. About This Guide Warning Red Hat is currently reviewing the information and procedures provided in this guide for this release. This document is based on the Red Hat OpenStack Platform 12 document, available at https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/?version=12 . If you require assistance for the current Red Hat OpenStack Platform release, please contact Red Hat support. This document provides an overview of the logging and monitoring capabilities that are available in a Red Hat OpenStack Platform environment, and how to troubleshoot possible issues.

Commands:
Chapter 10. Rule Audit Rule audit allows the auditing of rules which have been triggered by all the rules that were activated at some point. The Rule Audit list view shows you a list of every time an event came in that matched a condition within a rulebook and triggered an action. The list shows you rules within your rulebook and each heading matches up to a rule that has been executed. 10.1. Viewing rule audit details From the Rule Audit list view you can check the event that triggered specific actions. Procedure From the navigation panel select Automation Decisions Rule Audit . Select the desired rule, this brings you to the Details tab. From here you can view when it was created, when it was last fired, and the rulebook activation that it corresponds to. 10.2. Viewing rule audit events Procedure From the navigation panel, select Automation Decisions Rule Audit . Select the desired rule, this brings you to the Details tab. To view all the events that triggered an action, select the Events tab. This shows you the event that triggered actions. Select an event to view the Event log , along with the Source type and Timestamp . 10.3. Viewing rule audit actions Procedure From the navigation panel select Automation Decisions Rule Audit . Select the desired rule, then select the Actions tab. From here you can view executed actions that were taken. Some actions are linked out to Automation Execution where you can view the output.

Commands:
22.7. The VDSM to Network Name Mapping Tool 22.7.1. Mapping VDSM Names to Logical Network Names If the name of a logical network is longer than 15 characters or contains non-ASCII characters, the system automatically generates an on-host identifier ( vdsm_name ) name; it comprises the letters on and the first 13 characters of the network's unique identifier, for example, ona1b2c3d4e5f6g . It is this name that appears in the host's log files. To view a list of logical network names and their auto-generated network name, use the VDSM-to-Network-Name Mapping tool located in /usr/share/ovirt-engine/bin/ . Procedure The first time you run the tool, define a PASSWORD environment variable, which is the password of a database user with read access to the Manager database. For example, run: Run the VDSM-to-Network-Name Mapping tool: where USER is the database user with read access to the Manager database, whose password is assigned to the PASSWORD environment variable. The tool displays a list of logical network names that are mapped to their equivalent on-host identifiers. Additional Flags You can run the tool with the following flags: --host is the hostname/IP address of the database server. The default value is localhost . --port is the port number of the database server. The default value is 5432 . --database is the name of the database. The default value is engine , which is the Manager database. --secure enables a secure connection with the database. By default the tool is run without a secure connection.

Commands:
export PASSWORD= DatabaseUserPassword
vdsm_to_network_name_map --user USER
4.4.6. Removing Logical Volumes To remove an inactive logical volume, use the lvremove command. If the logical volume is currently mounted, you must close the volume with the umount command before removing it. In addition, in a clustered environment you must deactivate a logical volume before it can be removed. The following command removes the logical volume /dev/testvg/testlv . from the volume group testvg . Note that in this case the logical volume has not been deactivated. You could explicitly deactivate the logical volume before removing it with the lvchange -an command, in which case you would not see the prompt verifying whether you want to remove an active logical volume.

Commands:
lvremove /dev/testvg/testlv Do you really want to remove active logical volume "testlv"? [y/n]: y Logical volume "testlv" successfully removed
5.4. JDBC API Functionality The transaction scopes in Section 5.1, "Transaction Support" map to the following JDBC modes: Command Connection autoCommit property set to true. Local Connection autoCommit property set to false. The transaction is committed by setting autoCommit to true or calling java.sql.Connection.commit . The transaction can be rolled back by a call to java.sql.Connection.rollback . Global The XAResource interface provided by an XAConnection is used to control the transaction. Note that XAConnections are available only if JBoss Data Virtualization is consumed through its XADataSource, org.teiid.jdbc.TeiidDataSource . JEE containers or data access APIs typically control XA transactions on behalf of application code.

Commands:
4.8. Starting the Load Balancer Add-On To start the Load Balancer Add-On, it is best to have two root terminals open simultaneously or two simultaneous root open ssh sessions to the primary LVS router. In one terminal, watch the kernel log messages with the command: tail -f /var/log/messages Then start the Load Balancer Add-On by typing the following command into the other terminal: /sbin/service pulse start Follow the progress of the pulse service's startup in the terminal with the kernel log messages. When you see the following output, the pulse daemon has started properly: gratuitous lvs arps finished To stop watching /var/log/messages , type Ctrl + c . From this point on, the primary LVS router is also the active LVS router. While you can make requests to the Load Balancer Add-On at this point, you should start the backup LVS router before putting the Load Balancer Add-On into service. To do this, simply repeat the process described above on the backup LVS router node. After completing this final step, the Load Balancer Add-On will be up and running.

Commands:
Chapter 26. Managing routing contexts The JMX Navigator view lets you suspend and resume running routing contexts. 26.1. Suspending operation of a routing context Overview The tooling enables you to suspend the operation of a routing context in the JMX Navigator view. Suspending context operation gracefully shuts down all routes in the context, but keeps them loaded in memory, so that they can resume operation. Procedure To suspend operation of a routing context: In the JMX Navigator view, expand the project's Camel Contexts node, and select the routing context whose operation you want to suspend. Right-click the selected routing context to open the context menu, and then select Suspend Camel Context . Note If Resume Camel Context appears on the context menu, operation of the context is already suspended. Related topics Section 26.2, "Resuming operation of a routing context" 26.2. Resuming operation of a routing context Overview The tooling lets you resume operation of a suspended routing context in the JMX Navigator view. Resuming operation of a context restarts all of the routes in it so that they can process messages. Procedure To resume operation of a routing context: In the JMX Navigator view, expand the project's Camel Contexts node, and select the routing context whose operation you want to resume. Right-click the selected context to open the context menu, and then select Resume Camel Context . Note If Suspend Camel Context appears in the context menu, the context and its routes are running. Related topics Section 26.1, "Suspending operation of a routing context"

Commands:
5.134. kdepim 5.134.1. RHBA-2012:1287 - kdepim bug fix update Updated kdepim packages that fix one bug are now available for Red Hat Enterprise Linux 6. The KDE Personal Information Management (kdepim) suite helps to organize your mail, tasks, appointments, and contacts. Bug Fix BZ# 811125 Prior to this update, the cyrus-sasl-plain package was not a dependency of the kdepim package. As a consequence, Kmail failed to send mail. This update modifies the underlying code to include the cyrus-sasl-plain dependency. All users of kdepim are advised to upgrade to these updated packages, which fix this bug.

Commands:
3.6. Allowing Read-Only Access to the History Database To allow access to the history database without allowing edits, you must create a read-only PostgreSQL user that can log in to and read from the ovirt_engine_history database. This procedure must be executed on the system on which the history database is installed. Allowing Read-Only Access to the History Database Log in as root to the postgres user shell: # su - postgres Create the user to be granted read-only access to the history database: # psql -U postgres -c "CREATE ROLE username WITH LOGIN ENCRYPTED PASSWORD ' password ';" -d ovirt_engine_history Grant the newly created user permission to connect to the history database: # psql -U postgres -c "GRANT CONNECT ON DATABASE ovirt_engine_history TO username ;" Grant the newly created user usage of the public schema: # psql -U postgres -c "GRANT USAGE ON SCHEMA public TO username ;" ovirt_engine_history Generate the rest of the permissions that will be granted to the newly created user and save them to a file: # psql -U postgres -c "SELECT 'GRANT SELECT ON ' || relname || ' TO username ;' FROM pg_class JOIN pg_namespace ON pg_namespace.oid = pg_class.relnamespace WHERE nspname = 'public' AND relkind IN ('r', 'v');" --pset=tuples_only=on ovirt_engine_history > grant.sql Use the file you created in the step to grant permissions to the newly created user: # psql -U postgres -f grant.sql ovirt_engine_history Remove the file you used to grant permissions to the newly created user: # rm grant.sql Exit the postgres user shell by pressing Ctrl + d . Add the following lines for the newly created user to /var/lib/pgsql/data/pg_hba.conf preceding the line beginning local all all : # TYPE DATABASE USER ADDRESS METHOD host ovirt_engine_history username 0.0.0.0/0 md5 host ovirt_engine_history username ::0/0 md5 local all all peer Reload the PostgreSQL service: # systemctl reload postgresql To test the read-only user's access permissions: To exit the ovirt_engine_history database, enter \q . The read-only user's SELECT statements against tables and views in the ovirt_engine_history database succeed, while modifications fail.

Commands:
su - postgres
psql -U postgres -c "CREATE ROLE username WITH LOGIN ENCRYPTED PASSWORD ' password ';" -d ovirt_engine_history
psql -U postgres -c "GRANT CONNECT ON DATABASE ovirt_engine_history TO username ;"
psql -U postgres -c "GRANT USAGE ON SCHEMA public TO username ;" ovirt_engine_history
psql -U postgres -c "SELECT 'GRANT SELECT ON ' || relname || ' TO username ;' FROM pg_class JOIN pg_namespace ON pg_namespace.oid = pg_class.relnamespace WHERE nspname = 'public' AND relkind IN ('r', 'v');" --pset=tuples_only=on ovirt_engine_history > grant.sql
psql -U postgres -f grant.sql ovirt_engine_history
rm grant.sql
TYPE DATABASE USER ADDRESS METHOD host ovirt_engine_history username 0.0.0.0/0 md5 host ovirt_engine_history username ::0/0 md5 local all all peer
systemctl reload postgresql
su - postgres -c 'psql -U username ovirt_engine_history -h localhost' Password for user username: psql (9.2.23) Type "help" for help. ovirt_engine_history=>
E.3. Sample Metadata The following shows an example of LVM volume group metadata for a volume group called myvg .

Commands:
Generated by LVM2: Tue Jan 30 16:28:15 2007 contents = "Text Format Volume Group" version = 1 description = "Created *before* executing 'lvextend -L+5G /dev/myvg/mylv /dev/sdc'" creation_host = "tng3-1" # Linux tng3-1 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 creation_time = 1170196095 # Tue Jan 30 16:28:15 2007 myvg { id = "0zd3UT-wbYT-lDHq-lMPs-EjoE-0o18-wL28X4" seqno = 3 status = ["RESIZEABLE", "READ", "WRITE"] extent_size = 8192 # 4 Megabytes max_lv = 0 max_pv = 0 physical_volumes { pv0 { id = "ZBW5qW-dXF2-0bGw-ZCad-2RlV-phwu-1c1RFt" device = "/dev/sda" # Hint only status = ["ALLOCATABLE"] dev_size = 35964301 # 17.1491 Gigabytes pe_start = 384 pe_count = 4390 # 17.1484 Gigabytes } pv1 { id = "ZHEZJW-MR64-D3QM-Rv7V-Hxsa-zU24-wztY19" device = "/dev/sdb" # Hint only status = ["ALLOCATABLE"] dev_size = 35964301 # 17.1491 Gigabytes pe_start = 384 pe_count = 4390 # 17.1484 Gigabytes } pv2 { id = "wCoG4p-55Ui-9tbp-VTEA-jO6s-RAVx-UREW0G" device = "/dev/sdc" # Hint only status = ["ALLOCATABLE"] dev_size = 35964301 # 17.1491 Gigabytes pe_start = 384 pe_count = 4390 # 17.1484 Gigabytes } pv3 { id = "hGlUwi-zsBg-39FF-do88-pHxY-8XA2-9WKIiA" device = "/dev/sdd" # Hint only status = ["ALLOCATABLE"] dev_size = 35964301 # 17.1491 Gigabytes pe_start = 384 pe_count = 4390 # 17.1484 Gigabytes } } logical_volumes { mylv { id = "GhUYSF-qVM3-rzQo-a6D2-o0aV-LQet-Ur9OF9" status = ["READ", "WRITE", "VISIBLE"] segment_count = 2 segment1 { start_extent = 0 extent_count = 1280 # 5 Gigabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 0 ] } segment2 { start_extent = 1280 extent_count = 1280 # 5 Gigabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv1", 0 ] } } } }
7.241. subscription-manager 7.241.1. RHBA-2013:0350 - subscription-manager bug fix and enhancement update Updated subscription-manager packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The subscription-manager packages provide programs and libraries to allow users to manage subscriptions and yum repositories from the Red Hat Entitlement platform. Note The subscription-manager packages have been upgraded to upstream version 1.1.15, which provides a number of bug fixes and enhancements over the version. (BZ# 860291 ) Bug Fixes BZ# 785265 The dbus packages, which contain the D-BUS communication system, are not included in the minimal installation of Red Hat Enterprise Linux. However, the subscription-manager utility depends on dbus, which could previously cause subscription-manager to terminate unexpectedly with a traceback during the registration process. The system was registered successfully but the rhsmcertd daemon was not able to communicate with subscription manager servers, such as candlepin, Subscription Asset Manager, or katello. With this update, subscription-manager exits without a traceback when dbus is not present on the system. To ensure proper communication with the subscription manager servers, install dbus manually by running "yum install dbus". BZ# 865954 Due to an incorrect error handling of invalid system names, the system could be left in unusable state during the first boot process. The handling of invalid system names has been fixed and first boot proceeds properly as expected. Enhancements BZ# 874749 With this update, the subscribe-manager "unsubscribe" command has been renamed to "remove". BZ# 874776 , BZ# 874804 With this update, the subscribe-manager "subscribe" command has been renamed to "attach". This change includes also the references to the "subscribe" command, such as "--auto-subscribe", which has been renamed to "--auto-attach". All users of subscription-manager are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands: