mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 126. KafkaBridgeHttpConfig schema reference Used in: KafkaBridgeSpec Full list of KafkaBridgeHttpConfig schema properties Configures HTTP access to a Kafka cluster for the Kafka Bridge. The default HTTP configuration is for the Kafka Bridge to listen on port 8080. 126.1. cors As well as enabling HTTP access to a Kafka cluster, HTTP properties provide the capability to enable and define access control for the Kafka Bridge through Cross-Origin Resource Sharing (CORS). CORS is a HTTP mechanism that allows browser access to selected resources from more than one origin. To configure CORS, you define a list of allowed resource origins and HTTP access methods. For the origins, you can use a URL or a Java regular expression. Example Kafka Bridge HTTP configuration apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # ... http: port: 8080 cors: allowedOrigins: "https://strimzi.io" allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH" # ... 126.2. KafkaBridgeHttpConfig schema properties Property Property type Description port integer The port which is the server listening on. cors KafkaBridgeHttpCors CORS configuration for the HTTP Bridge.

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaBridge metadata: name: my-bridge spec: # http: port: 8080 cors: allowedOrigins: "https://strimzi.io" allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH" #
Chapter 3. User tasks 3.1. Creating applications from installed Operators This guide walks developers through an example of creating applications from an installed Operator using the OpenShift Dedicated web console. 3.1.1. Creating an etcd cluster using an Operator This procedure walks through creating a new etcd cluster using the etcd Operator, managed by Operator Lifecycle Manager (OLM). Prerequisites Access to an OpenShift Dedicated cluster. The etcd Operator already installed cluster-wide by an administrator. Procedure Create a new project in the OpenShift Dedicated web console for this procedure. This example uses a project called my-etcd . Navigate to the Operators Installed Operators page. The Operators that have been installed to the cluster by the dedicated-admin and are available for use are shown here as a list of cluster service versions (CSVs). CSVs are used to launch and manage the software provided by the Operator. Tip You can get this list from the CLI using: USD oc get csv On the Installed Operators page, click the etcd Operator to view more details and available actions. As shown under Provided APIs , this Operator makes available three new resource types, including one for an etcd Cluster (the EtcdCluster resource). These objects work similar to the built-in native Kubernetes ones, such as Deployment or ReplicaSet , but contain logic specific to managing etcd. Create a new etcd cluster: In the etcd Cluster API box, click Create instance . The page allows you to make any modifications to the minimal starting template of an EtcdCluster object, such as the size of the cluster. For now, click Create to finalize. This triggers the Operator to start up the pods, services, and other components of the new etcd cluster. Click the example etcd cluster, then click the Resources tab to see that your project now contains a number of resources created and configured automatically by the Operator. Verify that a Kubernetes service has been created that allows you to access the database from other pods in your project. All users with the edit role in a given project can create, manage, and delete application instances (an etcd cluster, in this example) managed by Operators that have already been created in the project, in a self-service manner, just like a cloud service. If you want to enable additional users with this ability, project administrators can add the role using the following command: USD oc policy add-role-to-user edit <user> -n <target_project> You now have an etcd cluster that will react to failures and rebalance data as pods become unhealthy or are migrated between nodes in the cluster. Most importantly, dedicated-admins or developers with proper access can now easily use the database with their applications.

Commands:
oc get csv
oc policy add-role-to-user edit <user> -n <target_project>
15.2. Removing Swap Space Sometimes it can be prudent to reduce swap space after installation. For example, you have downgraded the amount of RAM in your system from 1 GB to 512 MB, but there is 2 GB of swap space still assigned. It might be advantageous to reduce the amount of swap space to 1 GB, since the larger 2 GB could be wasting disk space. You have three options: remove an entire LVM2 logical volume used for swap, remove a swap file, or reduce swap space on an existing LVM2 logical volume. 15.2.1. Reducing Swap on an LVM2 Logical Volume To reduce an LVM2 swap logical volume (assuming /dev/VolGroup00/LogVol01 is the volume you want to reduce): Procedure 15.3. Reducing an LVM2 Swap Logical Volume Disable swapping for the associated logical volume: Reduce the LVM2 logical volume by 512 MB: Format the new swap space: Activate swap on the logical volume: To test if the swap logical volume was successfully reduced, inspect active swap space: 15.2.2. Removing an LVM2 Logical Volume for Swap To remove a swap volume group (assuming /dev/VolGroup00/LogVol02 is the swap volume you want to remove): Procedure 15.4. Remove a Swap Volume Group Disable swapping for the associated logical volume: Remove the LVM2 logical volume: Remove the following associated entry from the /etc/fstab file: Regenerate mount units so that your system registers the new configuration: Remove all references to the removed swap storage from the /etc/default/grub file: Rebuild the grub configuration: on BIOS-based machines, run: on UEFI-based machines, run: To test if the logical volume was successfully removed, inspect active swap space: 15.2.3. Removing a Swap File To remove a swap file: Procedure 15.5. Remove a Swap File At a shell prompt, execute the following command to disable the swap file (where /swapfile is the swap file): Remove its entry from the /etc/fstab file. Regenerate mount units so that your system registers the new configuration: Remove the actual file:

Commands:
swapoff -v /dev/VolGroup00/LogVol01
lvreduce /dev/VolGroup00/LogVol01 -L -512M
mkswap /dev/VolGroup00/LogVol01
swapon -v /dev/VolGroup00/LogVol01
cat /proc/swaps free -h
swapoff -v /dev/VolGroup00/LogVol02
lvremove /dev/VolGroup00/LogVol02
/dev/VolGroup00/LogVol02 swap swap defaults 0 0
systemctl daemon-reload
vi /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
cat /proc/swaps free -h
swapoff -v /swapfile
systemctl daemon-reload
rm /swapfile
30.2. Configure Server Hinting (Remote Client-Server Mode) In Red Hat JBoss Data Grid's Remote Client-Server mode, Server Hinting is configured in the JGroups subsystem on the transport element for the default stack, as follows: Procedure 30.1. Configure Server Hinting in Remote Client-Server Mode Find the JGroups subsystem configuration Enable Server Hinting via the transport Element Set the site ID using the site parameter. Set the rack ID using the rack parameter. Set the machine ID using the machine parameter. Report a bug

Commands:
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="USD{jboss.default.jgroups.stack:udp}"> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp" site="USD{jboss.jgroups.transport.site:s1}" rack="USD{jboss.jgroups.transport.rack:r1}" machine="USD{jboss.jgroups.transport.machine:m1}"> <!-- Additional configuration elements here --> </transport> </stack> </subsystem>
4.12. Prioritizing and Disabling SELinux Policy Modules The SELinux module storage in /etc/selinux/ allows using a priority on SELinux modules. Enter the following command as root to show two module directories with a different priority: While the default priority used by semodule utility is 400, the priority used in selinux-policy packages is 100, so you can find most of the SELinux modules installed with the priority 100. You can override an existing module with a modified module with the same name using a higher priority. When there are more modules with the same name and different priorities, only a module with the highest priority is used when the policy is built. Example 4.1. Using SELinux Policy Modules Priority Prepare a new module with modified file context. Install the module with the semodule -i command and set the priority of the module to 400. We use sandbox.pp in the following example. To return back to the default module, enter the semodule -r command as root: Disabling a System Policy Module To disable a system policy module, enter the following command as root: Warning If you remove a system policy module using the semodule -r command, it is deleted on your system's storage and you cannot load it again. To avoid unnecessary reinstallations of the selinux-policy-targeted package for restoring all system policy modules, use the semodule -d command instead.

Commands:
~]# ls /etc/selinux/targeted/active/modules 100 400 disabled
~]# semodule -X 400 -i sandbox.pp ~]# semodule --list-modules=full | grep sandbox 400 sandbox pp 100 sandbox pp
~]# semodule -X 400 -r sandbox libsemanage.semanage_direct_remove_key: sandbox module at priority 100 is now active.
semodule -d MODULE_NAME
16.3. Synchronizing Passwords Password changes in a Directory Server entry can be synchronized to password attributes in Active Directory entries by using the Password Sync utility. When passwords are synchronized, password policies are enforced on each sync peer locally. The syntax or minimum length requirements on the Directory Server apply when the password is changed in the Directory Server. When the changed password is synchronized over to the Windows server, the Windows password policy is enforced. Important The password policies themselves are not synchronized. Configuration information is kept locally and cannot be synchronized, including the password change history and the account lockout counters. When configuring a password policy for synchronization, consider the following points: The Password Sync utility must be installed locally on the Windows machine that will be synchronized with a Directory Server. Password Sync can only link the Windows machine to a single Directory Server; to sync changes with multiple Directory Server instances, configure the Directory Server for multi-supplier replication. Password expiration warnings and times, failed bind attempts, and other password-related information is enforced locally per server and is not synchronized between sync peer servers. On the Directory Server instance that has the replication agreement with the Windows server configured, set the nsslapd-unhashed-pw-switch parameter in the cn=config entry to on . The same bind behavior should occur on all servers. Make sure to create the same or similar password policies on both Directory Server and Active Directory servers. Entries that are created for synchronization (for example, the server identities) need to have passwords that never expire. To make sure that these special users have passwords that do not expire, add the passwordExpirationTime attribute to the Directory Server entry, and give it a value of 20380119031407Z (the top of the valid range).

Commands:
Chapter 332. String Encoding DataFormat Available as of Camel version 2.12 The String Data Format is a textual based format that supports encoding. 332.1. Options The String Encoding dataformat supports 2 options, which are listed below. Name Default Java Type Description charset String Sets an encoding to use. Will by default use the JVM platform default charset. contentTypeHeader false Boolean Whether the data format should set the Content-Type header with the type from the data format if the data format is capable of doing so. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSon etc. 332.2. Marshal In this example we marshal the file content to String object in UTF-8 encoding. from("file://data.csv").marshal().string("UTF-8").to("jms://myqueue"); 332.3. Unmarshal In this example we unmarshal the payload from the JMS queue to a String object using UTF-8 encoding, before its processed by the newOrder processor. from("jms://queue/order").unmarshal().string("UTF-8").processRef("newOrder"); 332.4. Dependencies This data format is provided in camel-core so no additional dependencies is needed.

Commands:
from("file://data.csv").marshal().string("UTF-8").to("jms://myqueue");
from("jms://queue/order").unmarshal().string("UTF-8").processRef("newOrder");
probe::scsi.ioentry Name probe::scsi.ioentry - Prepares a SCSI mid-layer request Synopsis scsi.ioentry Values req_addr The current struct request pointer, as a number disk_major The major number of the disk (-1 if no information) device_state_str The current state of the device, as a string disk_minor The minor number of the disk (-1 if no information) device_state The current state of the device

Commands:
4.2.3. Main Memory -- RAM RAM makes up the bulk of electronic storage on present-day computers. It is used as storage for both data and programs while those data and programs are in use. The speed of RAM in most systems today lies between the speed of cache memory and that of hard drives, and is much closer to the former than the latter. The basic operation of RAM is actually quite straightforward. At the lowest level, there are the RAM chips -- integrated circuits that do the actual "remembering." These chips have four types of connections to the outside world: Power connections (to operate the circuitry within the chip) Data connections (to enable the transfer of data into or out of the chip) Read/Write connections (to control whether data is to be stored into or retrieved from the chip) Address connections (to determine where in the chip the data should be read/written) Here are the steps required to store data in RAM: The data to be stored is presented to the data connections. The address at which the data is to be stored is presented to the address connections. The read/write connection is set to write mode. Retrieving data is just as straightforward: The address of the desired data is presented to the address connections. The read/write connection is set to read mode. The desired data is read from the data connections. While these steps seem simple, they take place at very high speeds, with the time spent on each step measured in nanoseconds. Nearly all RAM chips created today are sold as modules . Each module consists of a number of individual RAM chips attached to a small circuit board. The mechanical and electrical layout of the module adheres to various industry standards, making it possible to purchase memory from a variety of vendors. Note The main benefit to a system using industry-standard RAM modules is that it tends to keep the cost of RAM low, due to the ability to purchase the modules from more than just the system manufacturer. Although most computers use industry-standard RAM modules, there are exceptions. Most notable are laptops (and even here some standardization is starting to take hold) and high-end servers. However, even in these instances, it is likely that third-party RAM modules are available, assuming the system is relatively popular and is not a completely new design.

Commands:
Chapter 22. Tracing latencies with trace-cmd The trace-cmd utility is a front end to the ftrace utility. By using trace-cmd , you can enable ftrace actions, without the need to write to the /sys/kernel/debug/tracing/ directory. trace-cmd does not add any overhead on its installation. Prerequisites You have administrator privileges. 22.1. Installing trace-cmd The trace-cmd utility provides a front-end to the ftrace utility. Prerequisites You have administrator privileges. Procedure Install the trace-cmd utility. 22.2. Running trace-cmd You can use the trace-cmd utility to access all ftrace functionalities. Prerequisites You have administrator privileges. Procedure Enter trace-cmd command where command is an ftrace option. Note See the trace-cmd(1) man page for a complete list of commands and options. Most of the individual commands also have their own man pages, trace-cmd- command . 22.3. trace-cmd examples The command examples show how to trace kernel functions by using the trace-cmd utility. Examples Enable and start recording functions executing within the kernel while myapp runs. This records functions from all CPUs and all tasks, even those not related to myapp . Display the result. Record only functions that start with sched while myapp runs. Enable all the IRQ events. Start the wakeup_rt tracer. Start the preemptirqsoff tracer, while disabling function tracing. Note The version of trace-cmd in RHEL 8 turns off ftrace_enabled instead of using the function-trace option. You can enable ftrace again with trace-cmd start -p function. Restore the state in which the system was before trace-cmd started modifying it. This is important if you want to use the debugfs file system after using trace-cmd , whether or not the system was restarted in the meantime. Trace a single trace point. Stop tracing. 22.4. Additional resources trace-cmd(1) man page on your system

Commands:
dnf install trace-cmd
trace-cmd record -p function myapp
trace-cmd report
trace-cmd record -p function -l 'sched * ' myapp
trace-cmd start -e irq
trace-cmd start -p wakeup_rt
trace-cmd start -p preemptirqsoff -d
trace-cmd start -p nop
trace-cmd record -e sched_wakeup ls /bin
trace-cmd record stop
Chapter 2. Red Hat Quay support Red Hat Quay provides support for the following: Multiple authentication and access methods Multiple storage backends Custom certificates for Quay , Clair , and storage backend containers Application registries Different container image types 2.1. Architecture Red Hat Quay includes several core components, both internal and external. For a fuller architectural breakdown, see the Red Hat Quay architecture guide. 2.1.1. Internal components Red Hat Quay includes the following internal components: Quay (container registry) . Runs the Quay container as a service, consisting of several components in the pod. Clair . Scans container images for vulnerabilities and suggests fixes. 2.1.2. External components Red Hat Quay includes the following external components: Database . Used by Red Hat Quay as its primary metadata storage. Note that this is not for image storage. Redis (key-value store) . Stores live builder logs and the Red Hat Quay tutorial. Also includes the locking mechanism that is required for garbage collection. Cloud storage . For supported deployments, one of the following storage types must be used: Public cloud storage . In public cloud environments, you should use the cloud provider's object storage, such as Amazon Web Services's Amazon S3 or Google Cloud's Google Cloud Storage. Private cloud storage . In private clouds, an S3 or Swift compliant Object Store is needed, such as Ceph RADOS, or OpenStack Swift. Warning Do not use "Locally mounted directory" Storage Engine for any production configurations. Mounted NFS volumes are not supported. Local storage is meant for Red Hat Quay test-only installations.

Commands:
6.2. Performing System Assessment Install the preupgrade-assistant The preupgrade-assistant is a tool that scans the existing Red Hat Enterprise Linux 6 system and checks whether it is ready to be upgraded. Subscribe to the required repositories and install the preupgrade-assistant tool using the following commands: Run the preupgrade tool Launch the preupgrade tool: Assess the results View the following result of the preupgrade tool in a browser: Make a note of all the components that are marked as Failed and Needs Action . Share the findings with the Red Hat executive assisting with the upgrade process. Check the SELinux policy in Red Hat Enterprise Linux 7 SELinux policies have changed between Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7. For a working SELinux policy in Red Hat Enterprise Linux 7, execute the following command: Uninstall Cluster and HA related packages Migration is not possible with Cluster and HA related packages installed on the system. Uninstall Cluster and HA related packages by executing the following command:

Commands:
subscription-manager repos --enable rhel-6-server-extras-rpms --enable rhel-6-server-optional-rpms yum install preupgrade-assistant preupgrade-assistant-el6toel7
preupg -v
/root/preupgrade/result.html
semodule -r sandbox
yum remove modcluster ricci openais corosync
11.5. Using the Same Service Principal for Multiple Services Within a cluster, the same service principal can be used for multiple services, spread across different machines. Retrieve a service principal using the ipa-getkeytab command. Either direct multiple servers or services to use the same file, or copy the file to individual servers as required.

Commands:
ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
Chapter 260. OSGi PAX Logging Component Available as of Camel version 2.6 The paxlogging component can be used in an OSGi environment to receive PaxLogging events and process them. 260.1. Dependencies Maven users need to add the following dependency to their pom.xml <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-paxlogging</artifactId> <version>USD{camel-version}</version> </dependency> where USD{camel-version } must be replaced by the actual version of Camel (2.6.0 or higher). 260.2. URI format paxlogging:appender[?options] where appender is the name of the pax appender that need to be configured in the PaxLogging service configuration. 260.3. URI options The OSGi PAX Logging component supports 2 options, which are listed below. Name Description Default Type bundleContext (consumer) The OSGi BundleContext is automatic injected by Camel BundleContext resolveProperty Placeholders (advanced) Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. true boolean The OSGi PAX Logging endpoint is configured using URI syntax: with the following path and query parameters: 260.3.1. Path Parameters (1 parameters): Name Description Default Type appender Required Appender is the name of the pax appender that need to be configured in the PaxLogging service configuration. String 260.3.2. Query Parameters (4 parameters): Name Description Default Type bridgeErrorHandler (consumer) Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. false boolean exceptionHandler (consumer) To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. ExceptionHandler exchangePattern (consumer) Sets the exchange pattern when the consumer creates an exchange. ExchangePattern synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean 260.4. Message body The in message body will be set to the received PaxLoggingEvent. 260.5. Example usage <route> <from uri="paxlogging:camel"/> <to uri="stream:out"/> </route> Configuration: log4j.rootLogger=INFO, out, osgi:VmLogAppender, osgi:camel

Commands:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-paxlogging</artifactId> <version>USD{camel-version}</version> </dependency>
paxlogging:appender[?options]
paxlogging:appender
<route> <from uri="paxlogging:camel"/> <to uri="stream:out"/> </route>
log4j.rootLogger=INFO, out, osgi:VmLogAppender, osgi:camel