mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix C. Using AMQ Broker with the examples The Red Hat build of Apache Qpid Proton DotNet examples require a running message broker with a queue named hello-world-example . Use the procedures below to install and start the broker and define the queue. C.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> . C.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 ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named hello-world-example . USD <broker-instance-dir> /bin/artemis queue create --name hello-world-example --address hello-world-example --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. C.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 2023-12-07 15:25:52 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 hello-world-example --address hello-world-example --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
5.129. kdeartwork 5.129.1. RHBA-2012:0450 - kdeartwork bug fix update Updated kdeartwork packages that fix one bug are now available for Red Hat Enterprise Linux 6. The K Desktop Environment (KDE) is a graphical desktop environment for the X Window System. The kdeartwork packages include styles, themes and screen savers for KDE. Bug Fix BZ# 736624 Previously, the KPendulum and KRotation screen savers, listed in the OpenGL group of KDE screen savers, produced only a blank screen. This update disables KPendulum and KRotation and none of them is listed in the OpenGL group anymore. All users of kdeartwork are advised to upgrade to these updated packages, which fix this bug.

Commands:
7.141. opencryptoki 7.141.1. RHBA-2015:1278 - opencryptoki bug fix and enhancement update Updated opencryptoki packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The opencryptoki packages contain version 2.11 of the PKCS#11 API, implemented for IBM Cryptocards, such as IBM 4764 and 4765 crypto cards. These packages includes support for the IBM 4758 Cryptographic CoProcessor (with the PKCS#11 firmware loaded), the IBM eServer Cryptographic Accelerator (FC 4960 on IBM eServer System p), the IBM Crypto Express2 (FC 0863 or FC 0870 on IBM System z), and the IBM CP Assist for Cryptographic Function (FC 3863 on IBM System z). The opencryptoki packages also bring a software token implementation that can be used without any cryptographic hardware. These packages contain the Slot Daemon (pkcsslotd) and general utilities. Note The opencryptoki packages have been upgraded to upstream version 3.2, which provides a number of bug fixes and enhancements over the version. (BZ# 1148134 ) Enhancements BZ# 1148734 This update enables Central Processors Assist for Cryptographic Functions (CPACF) Message Security Assist 4 (MSA-4) extensions with new modes of operation for opencryptoki on IBM System z. In addition, this hardware encryption improves performance on machines z196 and later. BZ# 11148133 This update also implements an opencryptoki token for access to the Enterprise PKCS#11 (EP11) features of the Crypto Express4S (CEX4S) adapter that implements certified PKCS#11 mechanism on IBM System z. Users of opencryptoki are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
probe::netfilter.ip.post_routing Name probe::netfilter.ip.post_routing - Called immediately before an outgoing IP packet leaves the computer Synopsis netfilter.ip.post_routing Values family IP address family outdev Address of net_device representing output device, 0 if unknown nf_repeat Constant used to signify a 'repeat' verdict ipproto_tcp Constant used to signify that the packet protocol is TCP indev_name Name of network device packet was received on (if known) nf_stolen Constant used to signify a 'stolen' verdict length The length of the packet buffer contents, in bytes urg TCP URG flag (if protocol is TCP; ipv4 only) psh TCP PSH flag (if protocol is TCP; ipv4 only) rst TCP RST flag (if protocol is TCP; ipv4 only) protocol Packet protocol from driver (ipv4 only) nf_stop Constant used to signify a 'stop' verdict nf_accept Constant used to signify an 'accept' verdict outdev_name Name of network device packet will be routed to (if known) iphdr Address of IP header fin TCP FIN flag (if protocol is TCP; ipv4 only) syn TCP SYN flag (if protocol is TCP; ipv4 only) ipproto_udp Constant used to signify that the packet protocol is UDP ack TCP ACK flag (if protocol is TCP; ipv4 only) nf_queue Constant used to signify a 'queue' verdict dport TCP or UDP destination port (ipv4 only) pf Protocol family -- either " ipv4 " or " ipv6 " daddr A string representing the destination IP address nf_drop Constant used to signify a 'drop' verdict indev Address of net_device representing input device, 0 if unknown saddr A string representing the source IP address sport TCP or UDP source port (ipv4 only)

Commands:
Chapter 7. Managing logical volumes using the Web Console 7.1. Activating a logical volume using the Web Console Follow these instructions to activate a logical volume using the Web Console. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click the logical volume. Click Activate . 7.2. Creating a thinly provisioned logical volume using the Web Console Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click Create Thin Volume beside the thin pool that should host the volume. Figure 7.1. A thin pool The Create Thin Volume window opens. Specify a Name for the new volume. Specify a Size for the new volume. Click Create . The new volume appears in the list of logical volumes. 7.3. Creating a thickly provisioned logical volume using the Web Console Follow these instructions to create a logical thin pool using the Web Console. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click + Create new Logical Volume . The Create Logical Volume window opens. Figure 7.2. The Create Logical Volume window Specify a Name for your logical volume. Set Purpose to Block device for file systems . Specify a Size for your logical volume. Click Create . Your new logical volume appears in the list of logical volumes in this volume group. 7.4. Deactivating a logical volume using the Web Console Follow these instructions to deactivate a logical volume using the Web Console. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click the logical volume. Click Deactivate . Figure 7.3. The logical volume summary 7.5. Deleting a logical volume using the Web Console Follow these instructions to delete a thinly- or thickly-provisioned logical volume. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click the logical volume. Click Delete in the logical volume summary. Click Delete to confirm deletion. 7.6. Growing a logical volume using the Web Console Follow these instructions to increase the size of a logical volume using the Web Console. Log in to the Web Console. Click the hostname Storage . Click the volume group. The Volume Group Overview page opens. Click the logical volume. On the Volume subtab, click Grow . Figure 7.4. Logical Volume section expanded The Grow Logical Volume window opens. Figure 7.5. The Grow Logical Volume window Specify the new Size of the logical volume. Click Grow .

Commands:
10.10. Quorum Disk Does Not Appear as Cluster Member If you have configured your system to use a quorum disk but the quorum disk does not appear as a member of your cluster, you can perform the following steps. Review the /var/log/cluster/qdiskd.log file. Run ps -ef | grep qdisk to determine if the process is running. Ensure that <quorumd...> is configured correctly in the /etc/cluster/cluster.conf file. Enable debugging output for the qdiskd daemon. For information on enabling debugging in the /etc/cluster/cluster.conf file, see Section 8.7, "Configuring Debug Options" . For information on enabling debugging using luci , see Section 4.5.6, "Logging Configuration" . For information on enabling debugging with the ccs command, see Section 6.14.4, "Logging" . Note that it may take multiple minutes for the quorum disk to register with the cluster. This is normal and expected behavior.

Commands:
5.3. Configure CXF for a Web Service Data Source: WS-Security Prerequisites The web service data source must be configured and the ConfigFile and EndPointName properties must be configured for CXF. Procedure 5.2. Configure CXF for a Web Service Data Source: WS-Security Specify the CXF SecurityType Run the following command from within the Management CLI, using WSSecurity as the value for SecurityType : Modify the CXF Configuration File Open the CXF configuration file for the web service data source and add your desired properties. The following is an example of a web service data source CXF configuration file adding a timestamp to the SOAP header: Note A WSDL is not expected to describe the service being used. The Spring XML configuration file must contain the relevant policy configuration. The client port configuration is matched to the data source instance by the CONFIG-NAME . The configuration may contain other port configurations with different local names. References For more information about WS-Security and CXF configuration options refer to http://cxf.apache.org/docs/ws-security.html .

Commands:
/subsystem=resource-adapters/resource-adapter=webservice/connection-definitions=wsDS/config-properties=SecurityType:add(value=WSSecurity)
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.apache.org/jaxws" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd"> <jaxws:client name="{http://teiid.org}.teiid" createdFromAPI="true"> <jaxws:outInterceptors> <ref bean="Timestamp_Request"/> </jaxws:outInterceptors> </jaxws:client> <bean id="Timestamp_Request"> <constructor-arg> <map> <entry key="action" value="Timestamp"/> </map> </constructor-arg> </bean> </beans>
8.3.3. Huge Pages and Transparent Huge Pages (THP) x86 CPUs usually address memory in 4kB pages, but they are capable of using larger 2 MB or 1 GB pages known as huge pages . KVM guests can be deployed with huge page memory support in order to improve performance by increasing CPU cache hits against the Transaction Lookaside Buffer (TLB). A kernel feature enabled by default in Red Hat Enterprise Linux 6, huge pages can significantly increase performance, particularly for large memory and memory-intensive workloads. Red Hat Enterprise Linux 6 is able to more effectively manage large amounts of memory by increasing the page size through the use of huge pages. Red Hat Enterprise Linux 6.7 systems support both 2 MB and 1 GB huge pages, which can be allocated at boot or at runtime. See Section 8.3.3.3, "Enabling 1 GB huge pages for guests at boot or runtime" for instructions on enabling multiple huge page sizes. 8.3.3.1. Configuring Transparent Huge Pages Transparent huge pages (THP) automatically optimize system settings for performance. By allowing all free memory to be used as cache, performance is increased. As KSM can reduce the occurence of transparent huge pages, you may want to disable it before enabling THP. If you want to disable KSM, refer to Section 8.4.4, "Deactivating KSM" . Transparent huge pages are enabled by default. To check the current status, run: To enable transparent huge pages to be used by default, run: This will set /sys/kernel/mm/transparent_hugepage/enabled to always . To disable transparent huge pages: Transparent Huge Page support does not prevent the use of static huge pages. However, when static huge pages are not used, KVM will use transparent huge pages instead of the regular 4kB page size.

Commands:
cat /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/enabled
4.2. Keepalived Direct Routing Configuration Direct Routing configuration of Keepalived is similar in configuration with NAT. In the following example, Keepalived is configured to provide load balancing for a group of real servers running HTTP on port 80. To configure Direct Routing, change the lb_kind parameter to DR . Other configuration options are discussed in Section 4.1, "A Basic Keepalived configuration" . The following example shows the keepalived.conf file for the active server in a Keepalived configuration that uses direct routing. The following example shows the keepalived.conf file for the backup server in a Keepalived configuration that uses direct routing. Note that the state and priority values differ from the keepalived.conf file in the active server.

Commands:
global_defs { notification_email { admin@example.com } notification_email_from noreply_admin@example.com smtp_server 127.0.0.1 smtp_connect_timeout 60 } vrrp_instance RH_1 { state MASTER interface eth0 virtual_router_id 50 priority 100 advert_int 1 authentication { auth_type PASS auth_pass passw123 } virtual_ipaddress { 172.31.0.1 } } virtual_server 172.31.0.1 80 { delay_loop 10 lb_algo rr lb_kind DR persistence_timeout 9600 protocol TCP real_server 192.168.0.1 80 { weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } } real_server 192.168.0.2 80 { weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } } real_server 192.168.0.3 80 { weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } } }
global_defs { notification_email { admin@example.com } notification_email_from noreply_admin@example.com smtp_server 127.0.0.1 smtp_connect_timeout 60 } vrrp_instance RH_1 { state BACKUP interface eth0 virtual_router_id 50 priority 99 advert_int 1 authentication { auth_type PASS auth_pass passw123 } virtual_ipaddress { 172.31.0.1 } } virtual_server 172.31.0.1 80 { delay_loop 10 lb_algo rr lb_kind DR persistence_timeout 9600 protocol TCP real_server 192.168.0.1 80 { weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } } real_server 192.168.0.2 80 { weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } } real_server 192.168.0.3 80 { weight 1 TCP_CHECK { connect_timeout 10 connect_port 80 } } }
Chapter 1. Getting Started with Infinispan Query 1.1. Introduction The Red Hat JBoss Data Grid Library mode Querying API enables you to search for entries in the grid using values instead of keys. It provides features such as: Keyword, Range, Fuzzy, Wildcard, and Phrase queries Combining queries Sorting, filtering, and pagination of query results This API, which is based on Apache Lucene and Hibernate Search, is supported in JBoss Data Grid. Additionally, JBoss Data Grid provides an alternate mechanism that allows direct indexless searching. See Chapter 6, The Infinispan Query DSL for details. Report a bug

Commands:
5.187. mcelog 5.187.1. RHBA-2012:0779 - mcelog bug fix and enhancement update Updated mcelog packages that fix three bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The mcelog packages provide the mcelog daemon to collect and decode Machine Check Exception data on AMD64 and Intel 64 platforms. Bug Fixes BZ# 728265 Prior to this update, the mcelog README file contained references to nonexistent directories. This update removes these references and updates the file. BZ# 769363 Prior to this update, the mcelog daemon wrongly displayed an error that a certain microarchitecture was not supported even if the CPU was supported if mcelog was run on Intel CPUs only with architectural decoding enabled. This update removes this message. BZ# 784091 Prior to this update, a cron job tried to install regardless whether a system was supported or not. As a result, the mcelog daemon displayed the message "No such device" if mcelog was installed on unsupported systems. This update prevents the cron job from installing on unsupported processors. Enhancements BZ# 746785 Prior to this update, the mcelog daemon displayed the error "mcelog read: No such device" when running the unsupported AMD Family 16 microarchitecture or higher. This update adds a check to mcelog to determine what AMD processor family is used. If needed, the new message "CPU is unsupported" is displayed. BZ# 795508 Prior to this update, The cron file for mcelog did not use the "--supported" option. As a consequence, the "--supported" option did not correctly check whether the mcelog daemon worked. This update adds the "--supported" option to the crontab file and removes two redundant strings. All users of mcelog are advised to upgrade to these updated mcelog packages, which fix these bugs and add these enhancements.

Commands:
8.243. trace-cmd 8.243.1. RHBA-2014:1559 - trace-cmd bug fix update Updated trace-cmd packages that fix one bug are now available for Red Hat Enterprise Linux 6. The trace-cmd packages contain a command-line tool that interfaces with the ftrace utility in the kernel. Bug Fix BZ# 879814 Due to invalid pointers, executing the "trace-cmd split" or "trace-cmd report" commands after running latency tracers failed with a segmentation fault. With this update, additional checks have been added to ensure that the pointers are properly initialized before attempting to use them. As a result, the segmentation fault no longer occurs in the described scenario. Users of trace-cmd are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 6. Installing a three-node cluster on vSphere In OpenShift Container Platform version 4.17, you can install a three-node cluster on VMware vSphere. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 6.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: Configure your application ingress load balancer to route HTTP and HTTPS traffic to the control plane nodes. In a three-node cluster, the Ingress Controller pods run on the control plane nodes. For more information, see the "Load balancing requirements for user-provisioned infrastructure". After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on vSphere with user-provisioned infrastructure". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 6.2. steps Installing a cluster on vSphere with customizations Installing a cluster on vSphere with user-provisioned infrastructure

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 11. Enabling encryption on a vSphere cluster You can encrypt your virtual machines after installing OpenShift Container Platform 4.18 on vSphere by draining and shutting down your nodes one at a time. While each virtual machine is shutdown, you can enable encryption in the vCenter web interface. 11.1. Encrypting virtual machines You can encrypt your virtual machines with the following process. You can drain your virtual machines, power them down and encrypt them using the vCenter interface. Finally, you can create a storage class to use the encrypted storage. Prerequisites You have configured a Standard key provider in vSphere. For more information, see Adding a KMS to vCenter Server . Important The Native key provider in vCenter is not supported. For more information, see vSphere Native Key Provider Overview . You have enabled host encryption mode on all of the ESXi hosts that are hosting the cluster. For more information, see Enabling host encryption mode . You have a vSphere account which has all cryptographic privileges enabled. For more information, see Cryptographic Operations Privileges . Procedure Drain and cordon one of your nodes. For detailed instructions on node management, see "Working with Nodes". Shutdown the virtual machine associated with that node in the vCenter interface. Right-click on the virtual machine in the vCenter interface and select VM Policies Edit VM Storage Policies . Select an encrypted storage policy and select OK . Start the encrypted virtual machine in the vCenter interface. Repeat steps 1-5 for all nodes that you want to encrypt. Configure a storage class that uses the encrypted storage policy. For more information about configuring an encrypted storage class, see "VMware vSphere CSI Driver Operator". 11.2. Additional resources Working with nodes vSphere encryption Requirements for encrypting virtual machines

Commands: