mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix B. Revision History Note that revision numbers relate to the edition of this manual, not to version numbers of Red Hat Directory Server. Version Date and change Author 11.5-1 May 10 2022: Red Hat Directory Server 11.5 release of this guide Marc Muehlfeld 11.4-1 Nov 09 2021: Red Hat Directory Server 11.4 release of this guide Marc Muehlfeld 11.3-1 May 11 2021: Red Hat Directory Server 11.3 release of this guide Marc Muehlfeld 11.2-1 Nov 03 2020: Red Hat Directory Server 11.2 release of this guide Marc Muehlfeld 11.1-1 Apr 28 2020: Red Hat Directory Server 11.1 release of this guide Marc Muehlfeld 11.0-1 Nov 05 2019: Red Hat Directory Server 11.0 release of this guide Marc Muehlfeld

Commands:
Chapter 75. KafkaClientAuthenticationPlain schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationPlain schema properties To configure SASL-based PLAIN authentication, set the type property to plain . SASL PLAIN authentication mechanism requires a username and password. Warning The SASL PLAIN mechanism will transfer the username and password across the network in cleartext. Only use SASL PLAIN authentication if TLS encryption is enabled. 75.1. username Specify the username in the username property. 75.2. passwordSecret In the passwordSecret property, specify a link to a Secret containing the password. You can use the secrets created by the User Operator. If required, create a text file that contains the password, in cleartext, to use for authentication: echo -n PASSWORD > MY-PASSWORD .txt You can then create a Secret from the text file, setting your own field name (key) for the password: oc create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt Example Secret for PLAIN client authentication for Kafka Connect apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-password-field-name: LFTIyFRFlMmU2N2Tm The secretName property contains the name of the Secret and the password property contains the name of the key under which the password is stored inside the Secret . Important Do not specify the actual password in the password property. An example SASL based PLAIN client authentication configuration authentication: type: plain username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-password-field-name 75.3. KafkaClientAuthenticationPlain schema properties The type property is a discriminator that distinguishes use of the KafkaClientAuthenticationPlain type from KafkaClientAuthenticationTls , KafkaClientAuthenticationScramSha256 , KafkaClientAuthenticationScramSha512 , KafkaClientAuthenticationOAuth . It must have the value plain for the type KafkaClientAuthenticationPlain . Property Description passwordSecret Reference to the Secret which holds the password. PasswordSecretSource type Must be plain . string username Username used for the authentication. string

Commands:
echo -n PASSWORD > MY-PASSWORD .txt
create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-password-field-name: LFTIyFRFlMmU2N2Tm
authentication: type: plain username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-password-field-name
3.6. Displaying LVM Information with the lvm Command The lvm command provides several built-in options that you can use to display information about LVM support and configuration. lvm devtypes Displays the recognized build-in block device types (Red Hat Enterprise Linux release 6.6 and later). lvm formats Displays recognized metadata formats. lvm help Displays LVM help text. lvm segtypes Displays recognized logical volume segment types. lvm tags Displays any tags defined on this host. For information on LVM object tags, see Appendix D, LVM Object Tags . lvm version Displays the current version information.

Commands:
8.94. iprutils 8.94.1. RHBA-2014:1432 - iprutils bug fix and enhancement update Updated iprutils packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The iprutils packages provide utilities to manage and configure SCSI devices that are supported by the ipr SCSI storage device driver. This update also fixes the following bug: Note The iprutils package has been upgraded to upstream version 2.4.2, which provides a number of bug fixes and enhancements over the version. Specifically, this update provides support for the new vRAID Serial Attached SCSI (SAS) adapters. (BZ# 929292 ) This update also fixes the following bug: Bug Fix BZ# 1127825 Previously, information on "Read Intensive" disks did not display in the iprconfig menu. The underlying source code has been patched, and the disks information is now displayed correctly. The iprutils package has been upgraded to upstream version 2.4.2, which provides a number of bug fixes and enhancements over the version. Specifically, this update provides support for the new vRAID Serial Attached SCSI (SAS) adapters. (BZ#929292) Users of iprutils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 3. Analyzing your projects with the MTA extension You can analyze your projects with the MTA extension by creating a run configuration and running an analysis. 3.1. MTA extension interface The interface of the Migration Toolkit for Applications (MTA) extension is designed to make it easier for you to find information and perform actions: In the left pane, you can see a directory tree named Analysis Results with a report icon at its top. You can click the icon to open the MTA report in your browser. Beneath the report icon are the other elements of the tree: the applications analyzed by MTA, the rulesets used, and the issues discovered by the analysis. In the upper right pane, you can configure an analysis. In the lower right pane, you can see the settings of the configuration, including source, target, and advanced options. You can view the progress of an analysis in this pane. When the analysis is completed, you can click the Open Report button to open the MTA report, which describes any issues you need to address before you migrate or modernize your application. For more information, see Reviewing the reports in the CLI Guide . 3.2. Configuring a run configuration MTA extension interface You can configure multiple run configurations to run against each project you import to VS Code. Prerequisites mta-cli executable installed. You can download the mta-cli executable from mta download . Procedure In Extensions view, click the Migration Toolkit for Applications icon ( ) on the Activity bar. Click the + (plus sign) to Migration Toolkit for Applications to add a run configuration. Complete the following configuration fields: Name : Enter a meaningful name for the analysis configuration or accept the default. cli : Enter the path to the cli executable. For example: USDHOME/mta-cli-7.1.1.GA-redhat/bin/mta-cli . Input : Set to the path of the project that you have open within your IDE by clicking Add and doing one of the following: Enter the input file or directory and press Enter. Click Open File Explorer and select the directory. Target : Select one or more target migration paths. Right-click the run configuration and select Run . When the analysis is completed, you can click the Open Report button to open the MTA report, which describes any issues you need to address before you migrate or modernize your application. For more information, see Reviewing the reports in the CLI Guide .

Commands:
Appendix B. Using AMQ Broker with the examples The AMQ JavaScript examples require a running message broker with a queue named examples . Use the procedures below to install and start the broker and define the queue. B.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . B.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... B.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. B.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-05-07 10:16:18 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
Chapter 7. Troubleshooting 7.1. About troubleshooting Amazon EC2 EC2 provides an Alarm Status for each instance, indicating severe instance malfunction but the absence of such an alarm is no guarantee that the instance has started correctly and services are running properly. It is possible to use Amazon CloudWatch with its custom metric functionality to monitor instance services' health but use of an enterprise management solution is recommended. 7.2. Diagnostic information In case of a problem being detected by the JBoss Operations Network, Amazon CloudWatch or manual inspection, common sources of diagnostic information are: /var/log also contains all the logs collected from machine startup, JBoss EAP, httpd and most other services. JBoss EAP log files can be found in /opt/rh/eap8/root/usr/share/wildfly/ . Access to these files is only available using an SSH session. See Getting Started with Amazon EC2 Linux Instances for more information about how to configure and establish an SSH session with an Amazon EC2 instance. Revised on 2024-05-10 16:25:21 UTC

Commands:
10.11. Teiid Management CLI The AS CLI is a command line based administrative and monitoring tool for Teiid. AdminShell provides a binding into the Groovy scripting language and higher level methods that are often needed when interacting with Teiid. It is still useful to know the underlying CLI commands in many circumstances. The below is a series useful CLI commands for administering a Teiid Server. VDB Operations Source Operations Translator Operations Runtime Operations

Commands:
deploy adminapi-test-vdb.xml undeploy adminapi-test-vdb.xml /subsystem=teiid:restart-vdb(vdb-name=AdminAPITestVDB, vdb-version=1, model-names=TestModel) /subsystem=teiid:list-vdbs() /subsystem=teiid:get-vdb(vdb-name=AdminAPITestVDB,vdb-version=1) /subsystem=teiid:change-vdb-connection-type(vdb-name=AdminAPITestVDB, vdb-version=1,connection-type=ANY) /subsystem=teiid:add-data-role(vdb-name=AdminAPITestVDB, vdb-version=1, data-role=TestDataRole, mapped-role=test) /subsystem=teiid:remove-data-role(vdb-name=AdminAPITestVDB, vdb-version=1, data-role=TestDataRole, mapped-role=test)
/subsystem=teiid:add-source(vdb-name=AdminAPITestVDB, vdb-version=1, source-name=text-connector-test, translator-name=file, model-name=TestModel, ds-name=java:/test-file) /subsystem=teiid:remove-source(vdb-name=AdminAPITestVDB, vdb-version=1, source-name=text-connector-test, model-name=TestModel) /subsystem=teiid:update-source(vdb-name=AdminAPITestVDB, vdb-version=1, source-name=text-connector-test, translator-name=file, ds-name=java:/marketdata-file)
/subsystem=teiid:list-translators() /subsystem=teiid:get-translator(translator-name=file) /subsystem=teiid:read-translator-properties(translator-name=file,type=OVERRIDE) /subsystem=teiid:read-rar-description(rar-name=file)
/subsystem=teiid:workerpool-statistics() /subsystem=teiid:cache-types() /subsystem=teiid:clear-cache(cache-type=PREPARED_PLAN_CACHE) /subsystem=teiid:clear-cache(cache-type=QUERY_SERVICE_RESULT_SET_CACHE) /subsystem=teiid:clear-cache(cache-type=PREPARED_PLAN_CACHE, vdb-name=AdminAPITestVDB,vdb-version=1) /subsystem=teiid:clear-cache(cache-type=QUERY_SERVICE_RESULT_SET_CACHE, vdb-name=AdminAPITestVDB,vdb-version=1) /subsystem=teiid:cache-statistics(cache-type=PREPARED_PLAN_CACHE) /subsystem=teiid:cache-statistics(cache-type=QUERY_SERVICE_RESULT_SET_CACHE) /subsystem=teiid:engine-statistics() /subsystem=teiid:list-sessions() /subsystem=teiid:terminate-session(session=sessionid) /subsystem=teiid:list-requests() /subsystem=teiid:cancel-request(session=sessionId, execution-id=1) /subsystem=teiid:list-requests-per-session(session=sessionId) /subsystem=teiid:list-transactions() /subsystem=teiid:mark-datasource-available(ds-name=java:/accounts-ds) /subsystem=teiid:get-query-plan(session=sessionid,execution-id=1)
Chapter 2. Initial LVS Configuration After installing Red Hat Enterprise Linux, you must take some basic steps to set up both the LVS routers and the real servers. This chapter covers these initial steps in detail. Note The LVS router node that becomes the active node once LVS is started is also referred to as the primary node . When configuring LVS, use the Piranha Configuration Tool on the primary node. 2.1. Configuring Services on the LVS Routers The Red Hat Enterprise Linux installation program installs all of the components needed to set up LVS, but the appropriate services must be activated before configuring LVS. For both LVS routers, set the appropriate services to start at boot time. There are three primary tools available for setting services to activate at boot time under Red Hat Enterprise Linux: the command line program chkconfig , the ncurses-based program ntsysv , and the graphical Services Configuration Tool . All of these tools require root access. Note To attain root access, open a shell prompt and use the su - command followed by the root password. For example: On the LVS routers, there are three services which need to be set to activate at boot time: The piranha-gui service (primary node only) The pulse service The sshd service If you are clustering multi-port services or using firewall marks, you must also enable the iptables service. It is best to set these services to activate in both runlevel 3 and runlevel 5. To accomplish this using chkconfig , type the following command for each service: /sbin/chkconfig --level 35 daemon on In the above command, replace daemon with the name of the service you are activating. To get a list of services on the system as well as what runlevel they are set to activate on, issue the following command: /sbin/chkconfig --list Warning Turning any of the above services on using chkconfig does not actually start the daemon. To do this use the /sbin/service command. See Section 2.3, "Starting the Piranha Configuration Tool Service" for an example of how to use the /sbin/service command. For more information on runlevels and configuring services with ntsysv and the Services Configuration Tool , refer to the chapter titled "Controlling Access to Services" in the Red Hat Enterprise Linux System Administration Guide .

Commands:
su - root password
17.3. Linux RAID Subsystems RAID in Linux is composed of the following subsystems: Linux Hardware RAID controller drivers Hardware RAID controllers have no specific RAID subsystem in Linux. Because they use special RAID chipsets, hardware RAID controllers come with their own drivers; these drivers allow the system to detect the RAID sets as regular disks. mdraid The mdraid subsystem was designed as a software RAID solution for Linux; it is also the preferred solution for software RAID under Linux. This subsystem uses its own metadata format, generally referred to as native mdraid metadata. mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility. dmraid Device-mapper RAID or dmraid refers to device-mapper kernel code that offers the mechanism to piece disks together into a RAID set. This same kernel code does not provide any RAID configuration mechanism. dmraid is configured entirely in user-space, making it easy to support various on-disk metadata formats. As such, dmraid is used on a wide variety of firmware RAID implementations. dmraid also supports Intel firmware RAID, although Red Hat Enterprise Linux 6 uses mdraid to access Intel firmware RAID sets.

Commands:
Chapter 2. OpenStack Integration Test Suite Tests The OpenStack Integration Test Suite has many applications. It acts as a gate for commits to the OpenStack core projects, it can stress test to generate load on a cloud deployment, and it can perform CLI tests to check the response formatting of the command line. However, the functionality that we are concerned with are the scenario tests and API tests . These tests are run against your OpenStack cloud deployment. The following sections contain information about implementing each of these tests. 2.1. Scenario Tests Scenario tests simulate a typical end user action workflow to test the integration points between services. The testing framework conducts the configuration, tests the integration between services, and is then removed automatically. Tag the tests with the services that they relate to, to make it clear which client libraries the test uses. A scenario is based on a use case, for example: Upload an image to the Image Service Deploy an instance from the image Attach a volume to the instance Create a snapshot of the instance Detach the volume from the instance 2.2. API Tests API tests validate the OpenStack API. Tests use the OpenStack Integration Test Suite implementation of the OpenStack API. You can use both valid and invalid JSON to ensure that error responses are valid. You can run tests independently and you do not have to rely on the test state.

Commands:
32.2.4. Testing the Configuration Warning The commands below will cause the kernel to crash. Use caution when following these steps, and by no means use them on a production machine. To test the configuration, reboot the system with kdump enabled, and make sure that the service is running (see Section 12.3, "Running Services" for more information on how to run a service in Red Hat Enterprise Linux): Then type the following commands at a shell prompt: This will force the Linux kernel to crash, and the address - YYYY-MM-DD - HH:MM:SS /vmcore file will be copied to the location you have selected in the configuration (that is, to /var/crash/ by default).

Commands:
~]# service kdump status Kdump is operational
echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger
7.10. Additional Resources For more information about the Audit system, see the following sources. Online Sources The Linux Audit system project page: http://people.redhat.com/sgrubb/audit/ . Article Investigating kernel Return Codes with the Linux Audit System in the Hack In the Box magazine: http://magazine.hackinthebox.org/issues/HITB-Ezine-Issue-005.pdf . Installed Documentation Documentation provided by the audit package can be found in the /usr/share/doc/audit- version / directory. Manual Pages audispd.conf (5) auditd.conf (5) ausearch-expression (5) audit.rules (7) audispd (8) auditctl (8) auditd (8) aulast (8) aulastlog (8) aureport (8) ausearch (8) ausyscall (8) autrace (8) auvirt (8)

Commands:
Chapter 79. KafkaAutoRebalanceStatusBrokers schema reference Used in: KafkaAutoRebalanceStatus Property Property type Description mode string (one of [remove-brokers, add-brokers]) Mode for which there is an auto-rebalancing operation in progress or queued, when brokers are added or removed. The possible modes are add-brokers and remove-brokers . brokers integer array List of broker IDs involved in an auto-rebalancing operation related to the current mode. The list contains one of the following: Broker IDs for a current auto-rebalance. Broker IDs for a queued auto-rebalance (if a auto-rebalance is still in progress).

Commands:
C.3. Inheritance, the <resources> Block, and Reusing Resources Some resources benefit by inheriting values from a parent resource; that is commonly the case in an NFS service. Example C.5, "NFS Service Set Up for Resource Reuse and Inheritance" shows a typical NFS service configuration, set up for resource reuse and inheritance. Example C.5. NFS Service Set Up for Resource Reuse and Inheritance If the service were flat (that is, with no parent/child relationships), it would need to be configured as follows: The service would need four nfsclient resources - one per file system (a total of two for file systems), and one per target machine (a total of two for target machines). The service would need to specify export path and file system ID to each nfsclient, which introduces chances for errors in the configuration. In Example C.5, "NFS Service Set Up for Resource Reuse and Inheritance" however, the NFS client resources nfsclient:bob and nfsclient:jim are defined once; likewise, the NFS export resource nfsexport:exports is defined once. All the attributes needed by the resources are inherited from parent resources. Because the inherited attributes are dynamic (and do not conflict with one another), it is possible to reuse those resources - which is why they are defined in the resources block. It may not be practical to configure some resources in multiple places. For example, configuring a file system resource in multiple places can result in mounting one file system on two nodes, therefore causing problems.

Commands:
<resources> <nfsclient name="bob" target="bob.example.com" options="rw,no_root_squash"/> <nfsclient name="jim" target="jim.example.com" options="rw,no_root_squash"/> <nfsexport name="exports"/> </resources> <service name="foo"> <fs name="1" mountpoint="/mnt/foo" device="/dev/sdb1" fsid="12344"> <nfsexport ref="exports"> <!-- nfsexport's path and fsid attributes are inherited from the mountpoint & fsid attribute of the parent fs resource --> <nfsclient ref="bob"/> <!-- nfsclient's path is inherited from the mountpoint and the fsid is added to the options string during export --> <nfsclient ref="jim"/> </nfsexport> </fs> <fs name="2" mountpoint="/mnt/bar" device="/dev/sdb2" fsid="12345"> <nfsexport ref="exports"> <nfsclient ref="bob"/> <!-- Because all of the critical data for this resource is either defined in the resources block or inherited, we can reference it again! --> <nfsclient ref="jim"/> </nfsexport> </fs> <ip address="10.2.13.20"/> </service>