mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. Message delivery 8.1. Sending messages To send a message, create a connection, session, and sender link, then call the Sender.Send() method with a Message object. Example: Sending messages Connection connection = new Connection(new Address("amqp://example.com")); Session session = new Session(connection); SenderLink sender = new SenderLink(session, "sender-1", "jobs"); Message message = new Message("job-content"); sender.Send(message); For more information, see the Send.cs example . 8.2. Receiving messages To receive a message, create a connection, session, and receiver link, then call the Receiver.Receive() method and use the returned Message object. Example: Receiving messages Connection connection = new Connection(new Address("amqp://example.com")); Session session = new Session(connection); ReceiverLink receiver = new ReceiverLink(session, "receiver-1", "jobs"); Message message = receiver.Receive(); receiver.Accept(message); The Receiver.Accept() call tells the remote peer that the message was received and processed. For more information, see the Receive.cs example .

Commands:
Connection connection = new Connection(new Address("amqp://example.com")); Session session = new Session(connection); SenderLink sender = new SenderLink(session, "sender-1", "jobs"); Message message = new Message("job-content"); sender.Send(message);
Connection connection = new Connection(new Address("amqp://example.com")); Session session = new Session(connection); ReceiverLink receiver = new ReceiverLink(session, "receiver-1", "jobs"); Message message = receiver.Receive(); receiver.Accept(message);
Chapter 6. Device Drivers 6.1. New drivers Network drivers SYNOPSYS DESIGNWARE Ethernet XPCS driver (pcs-xpcs.ko.xz) INTEL 10/100/1000 Ethernet PCI driver (dwmac-intel.ko.xz) STMMAC 10/100/1000 Ethernet device driver (stmmac.ko.xz) Crypto IPSEC for Chelsio Terminator cards. (ch_ipsec.ko.xz): 1.0.0. Chelsio NIC TLS ULD driver (ch_ktls.ko.xz): 1.0.0. Microsoft Azure Network Adapter driver (mana.ko.xz) Core module for Qualcomm Atheros 802.11ax wireless LAN cards. (ath11k.ko.xz) Driver support for Qualcomm Technologies 802.11ax WLAN PCIe devices (ath11k_pci.ko.xz) MAC to optional PHY connection (phylink.ko.xz) Graphics drivers and miscellaneous drivers MC Driver for Intel client SoC using In-Band ECC (igen6_edac.ko.xz) Regmap SoundWire MBQ Module (regmap-sdw-mbq.ko.xz) Intel Platform Monitoring Technology PMT driver (intel_pmt.ko.xz) Intel PMT Crashlog driver (intel_pmt_crashlog.ko.xz) Sysfs structure for UV systems (uv_sysfs.ko.xz) Intel PMT Telemetry driver (intel_pmt_telemetry.ko.xz) Intel PMT Class driver (intel_pmt_class.ko.xz) AMD PMC Driver (amd-pmc.ko.xz) MHI Host Interface (mhi.ko.xz) Modem Host Interface (MHI) PCI controller driver (mhi_pci_generic.ko.xz) vDPA Device Simulator for block device (vdpa_sim_blk.ko.xz): 0.1 vDPA Device Simulator for networking device (vdpa_sim_net.ko.xz): 0.1 vp-vdpa (vp_vdpa.ko.xz): 1 Mellanox VDPA driver (mlx5_vdpa.ko.xz) Basic STM framing protocol driver (stm_p_basic.ko.xz) MIPI SyS-T STM framing protocol driver (stm_p_sys-t.ko.xz) QMI encoder/decoder helper (qmi_helpers.ko.xz) ACPI DPTF platform power driver (dptf_power.ko.xz) ACPI Platform profile sysfs interface (platform_profile.ko.xz) Intel Emmitsburg PCH pinctrl/GPIO driver (pinctrl-emmitsburg.ko.xz) Intel Alder Lake PCH pinctrl/GPIO driver (pinctrl-alderlake.ko.xz) MPI3 Storage Controller Device Driver (mpi3mr.ko.xz): 00.255.45.01 device-mapper multipath path selector that selects paths based on the CPU IO is being executed on (dm-io-affinity.ko.xz) device-mapper measured service time oriented path selector (dm-historical-service-time.ko.xz) 6.2. Updated drivers Network drivers Mellanox 5th generation network adapters (ConnectX series) core driver (mlx5_core.ko.xz) has been updated to version 4.18.0-348.el8.x86_64. Realtek RTL8152/RTL8153 Based USB Ethernet Adapters (r8152.ko.xz) has been updated to version v1.11.11. Graphics and miscellaneous driver updates LSI MPT Fusion SAS 3.0 Device Driver (mpt3sas.ko.xz) has been updated to version 37.101.00.00. Emulex LightPulse Fibre Channel SCSI driver (lpfc.ko.xz) has been updated to version 0:12.8.0.10. QLogic Fibre Channel HBA Driver (qla2xxx.ko.xz) has been updated to version 10.02.00.106-k. Driver for Microsemi Smart Family Controller version (smartpqi.ko.xz) has been updated to version 2.1.8-045. Broadcom MegaRAID SAS Driver (megaraid_sas.ko.xz) has been updated to version 07.717.02.00-rh1.

Commands:
Chapter 1. Introduction to Red Hat Certified Cloud and Service Provider Certification for Red Hat Enterprise Linux for SAP images policies 1.1. Audience Use this guide to understand the technical and operational certification requirements for CCSP Partners who want to offer Red Hat Enterprise Linux (RHEL) for SAP with High Availability and Update Services in Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or a managed service offerings. 1.2. Create value for our joint customers As a Certified Cloud and Service Provider (CCSP), you are required to certify images that you publish in a catalog. The RHEL for SAP with High Availability and Update Services image certification process includes a series of tests that provide your Red Hat customers an assurance that they will have a consistent experience across cloud providers. You are expected to have entered into certifications in good faith and for the interest of our joint customers. Customers will also have the confidence that their deployments are jointly supported by Red Hat and your organization ensuring the customer's experience comes with the highest level of support and good security practices. 1.3. Additional resources Red Hat Connect for Business Partners Red Hat Certified Cloud and Service Provider Certification Policy Guide

Commands:
7.2. RHEA-2014:1602 - new packages: cryptsetup-reencrypt New cryptsetup-reencrypt packages are now available for Red Hat Enterprise Linux 6. The cryptsetup-reencrypt packages provide the cryptsetup-reencrypt utility that can be used for offline re-encryption of a disk that is encrypted with Linux Unified Key Setup-on-disk-format (LUKS). These packages also include a dracut module required for re-encryption of a device that contains a root file system. This enhancement update adds the cryptsetup-reencrypt packages to Red Hat Enterprise Linux 6. The cryptsetup-reencrypt utility also facilitate the mass cloning of drives. (BZ# 1107729 , BZ# 847172 ) All users who require cryptsetup-reencrypt are advised to install these new packages.

Commands:
Chapter 12. Configuring kube-rbac-proxy for Eventing The kube-rbac-proxy component provides internal authentication and authorization capabilities for Knative Eventing. 12.1. Configuring kube-rbac-proxy resources for Eventing You can globally override resource allocation for the kube-rbac-proxy container by using the OpenShift Serverless Operator CR. Note You can also override resource allocation for a specific deployment. The following configuration sets Knative Eventing kube-rbac-proxy minimum and maximum CPU and memory allocation: KnativeEventing CR example apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4 1 Sets minimum CPU allocation. 2 Sets minimum RAM allocation. 3 Sets maximum CPU allocation. 4 Sets maximum RAM allocation. 12.2. Configuring kube-rbac-proxy resources for Knative for Apache Kafka You can globally override resource allocation for the kube-rbac-proxy container by using the OpenShift Serverless Operator CR. Note You can also override resource allocation for a specific deployment. The following configuration sets Knative Kafka kube-rbac-proxy minimum and maximum CPU and memory allocation: KnativeKafka CR example apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: name: knative-kafka namespace: knative-kafka spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4 1 Sets minimum CPU allocation. 2 Sets minimum RAM allocation. 3 Sets maximum CPU allocation. 4 Sets maximum RAM allocation.

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4
apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: name: knative-kafka namespace: knative-kafka spec: config: deployment: "kube-rbac-proxy-cpu-request": "10m" 1 "kube-rbac-proxy-memory-request": "20Mi" 2 "kube-rbac-proxy-cpu-limit": "100m" 3 "kube-rbac-proxy-memory-limit": "100Mi" 4
Chapter 5. Introducing metrics If you want to introduce metrics to your Streams for Apache Kafka Proxy deployment, you can configure an insecure HTTP and Prometheus endpoint (at /metrics ). Add the following to the ConfigMap resource that defines the Streams for Apache Kafka Proxy configuration: Minimal metrics configuration adminHttp: endpoints: prometheus: {} By default, the HTTP endpoint listens on 0.0.0.0:9190 . You can change the hostname and port as follows: Example metrics configuration with hostname and port adminHttp: host: localhost port: 9999 endpoints: prometheus: {} The example files provided with the proxy include a PodMonitor resource. If you have enabled monitoring in OpenShift for user-defined projects, you can use a PodMonitor resource to ingest the proxy metrics. Example PodMonitor resource configuration apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: proxy labels: app: proxy spec: selector: matchLabels: app: proxy namespaceSelector: matchNames: - proxy podMetricsEndpoints: - path: /metrics port: metrics

Commands:
adminHttp: endpoints: prometheus: {}
adminHttp: host: localhost port: 9999 endpoints: prometheus: {}
apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: proxy labels: app: proxy spec: selector: matchLabels: app: proxy namespaceSelector: matchNames: - proxy podMetricsEndpoints: - path: /metrics port: metrics
Chapter 4. Deploy the Shared File System Service with a CephFS Back End Once you create /home/stack/templates/manila-cephfsnative-config.yaml , log in as the stack user on the undercloud. Then, deploy the Shared File System service with a CephFS back end by including the following environment files: /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml - enables the Ceph MDS, which is required by Shared File System service when using a CephFS back end. /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml - deploys the Ceph cluster. /home/stack/templates/manila-cephfsnative-config.yaml - created earlier in Chapter 3, Edit the Environment File , and contains any settings to override defaults set in /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml . For example, if your OpenStack and Ceph settings are defined in /home/stack/templates/storage-environment.yaml , run: Important If you passed any extra environment files when you created the overcloud, pass them again here using the -e option to avoid making undesired changes to the overcloud. For more information, see Modifying the overcloud environment in the Director Installation and Usage guide.

Commands:
openstack overcloud deploy --templates -e /home/stack/templates/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml -e /home/stack/templates/manila-cephfsnative-config.yaml \
Chapter 8. Uninstalling a cluster on Alibaba Cloud You can remove a cluster that you deployed to Alibaba Cloud. 8.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
5.3. virt-install virt-install is a command-line tool for provisioning new virtual machines. It supports both text-based and graphical installations, using serial console, SDL, SPICE, or VNC client-server pair graphics. Installation media can be local, or exist remotely on an NFS, HTTP, or FTP server. The tool can also be configured to run unattended and kickstart the guest when installation is complete, allowing for easy automation of installation. This tool is installed as part of the python-virtinst package. Note Refer to the Red Hat Enterprise Linux 6 Virtualization Host Configuration and Guest Installation Guide for more information about virt-install .

Commands:
Chapter 3. Deploying Samba on Red Hat Gluster Storage 3.1. Prerequisites To install Samba on Red Hat Gluster Storage you require access to the installation media either through an ISO or a properly configured software repository. The Red Hat Gluster Storage server requirements are: You must install Red Hat Gluster Storage Server on the target server. Warning For layered installation of Red Hat Gluster Storage, ensure to have only the default Red Hat Enterprise Linux server installation, without the Samba or CTDB packages installed from Red Hat Enterprise Linux. The Samba version 3 is being deprecated from Red Hat Gluster Storage 3.0 Update 4. Further updates will not be provided for samba-3.x. It is recommended that you upgrade to Samba-4.x, which is provided in a separate channel or repository, for all updates including the security updates. CTDB version 2.5 is not supported from Red Hat Gluster Storage 3.1 Update 2. To use CTDB in Red Hat Gluster Storage 3.1.2 and later, you must upgrade the system to CTDB 4.x, which is provided in the Samba channel of Red Hat Gluster Storage. Downgrade of Samba from Samba 4.x to Samba 3.x is not supported. Ensure that Samba is upgraded on all the nodes simultaneously, as running different versions of Samba in the same cluster will lead to data corruption. Enable the channel where the Samba packages are available: For Red Hat Gluster Storage 3.5 on Red Hat Enterprise Linux 6.x If you have registered your machine using Red Hat Subscription Manager or Satellite server-6.x, enable the repository by running the following command: For Red Hat Gluster Storage 3.5 on Red Hat Enterprise Linux 7.7 and later If you have registered your machine using Red Hat Subscription Manager or Satellite server-7.x, enable the repository by running the following command: For Red Hat Gluster Storage 3.5 on Red Hat Enterprise Linux 8.2 and later If you have registered your machine using Red Hat Subscription Manager or Satellite server-8.x, enable the repository by running the following command:

Commands:
subscription-manager repos --enable=rh-gluster-3-samba-for-rhel-6-server-rpms
subscription-manager repos --enable=rh-gluster-3-samba-for-rhel-7-server-rpms
subscription-manager repos --enable=rh-gluster-3-samba-for-rhel-8-x86_64-rpms
Preface Once you have deployed a Red Hat Quay registry, there are many ways you can further configure and manage that deployment. Topics covered here include: Advanced Red Hat Quay configuration Setting notifications to alert you of a new Red Hat Quay release Securing connections with SSL/TLS certificates Directing action logs storage to Elasticsearch Configuring image security scanning with Clair Scan pod images with the Container Security Operator Integrate Red Hat Quay into OpenShift Container Platform with the Quay Bridge Operator Mirroring images with repository mirroring Sharing Red Hat Quay images with a BitTorrent service Authenticating users with LDAP Enabling Quay for Prometheus and Grafana metrics Setting up geo-replication Troubleshooting Red Hat Quay For a complete list of Red Hat Quay configuration fields, see the Configure Red Hat Quay page.

Commands:
function::ansi_set_color2 Name function::ansi_set_color2 - Set the ansi Select Graphic Rendition mode. Synopsis Arguments fg Foreground color to set. bg Background color to set. Description Sends ansi code for Select Graphic Rendition mode for the given forground color, Black (30), Blue (34), Green (32), Cyan (36), Red (31), Purple (35), Brown (33), Light Gray (37) and the given background color, Black (40), Red (41), Green (42), Yellow (43), Blue (44), Magenta (45), Cyan (46), White (47).

Commands:
ansi_set_color2(fg:long,bg:long)
A.13. VDSM Hook Examples The example hook scripts provided in this section are strictly not supported by Red Hat. You must ensure that any and all hook scripts that you install to your system, regardless of source, are thoroughly tested for your environment. Example A.5. NUMA Node Tuning Purpose: This hook script allows for tuning the allocation of memory on a NUMA host based on the numaset custom property. Where the custom property is not set no action is taken. Configuration String: The regular expression used allows the numaset custom property for a given virtual machine to specify both the allocation mode ( interleave , strict , preferred ) and the node to use. The two values are separated by a colon ( : ). The regular expression allows specification of the nodeset as: that a specific node ( numaset=strict:1 , specifies that only node 1 be used), or that a range of nodes be used ( numaset=strict:1-4 , specifies that nodes 1 through 4 be used), or that a specific node not be used ( numaset=strict:^3 , specifies that node 3 not be used), or any comma-separated combination of the above ( numaset=strict:1-4,6 , specifies that nodes 1 to 4, and 6 be used). Script: /usr/libexec/vdsm/hooks/before_vm_start/50_numa

Commands:
numaset=^(interleave|strict|preferred):[\^]?\d+(-\d+)?(,[\^]?\d+(-\d+)?)*USD
#!/usr/bin/python import os import sys import hooking import traceback ''' numa hook ========= add numa support for domain xml: <numatune> <memory mode="strict" nodeset="1-4,^3" /> </numatune> memory=interleave|strict|preferred numaset="1" (use one NUMA node) numaset="1-4" (use 1-4 NUMA nodes) numaset="^3" (don't use NUMA node 3) numaset="1-4,^3,6" (or combinations) syntax: numa=strict:1-4 ''' if os.environ.has_key('numa'): try: mode, nodeset = os.environ['numa'].split(':') domxml = hooking.read_domxml() domain = domxml.getElementsByTagName('domain')[0] numas = domxml.getElementsByTagName('numatune') if not len(numas) > 0: numatune = domxml.createElement('numatune') domain.appendChild(numatune) memory = domxml.createElement('memory') memory.setAttribute('mode', mode) memory.setAttribute('nodeset', nodeset) numatune.appendChild(memory) hooking.write_domxml(domxml) else: sys.stderr.write('numa: numa already exists in domain xml') sys.exit(2) except: sys.stderr.write('numa: [unexpected error]: %s\n' % traceback.format_exc()) sys.exit(2)
Chapter 32. Kickstart Installations 32.1. What are Kickstart Installations? Many system administrators would prefer to use an automated installation method to install Red Hat Enterprise Linux on their machines. To answer this need, Red Hat created the kickstart installation method. Using kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical installation. Kickstart files can be kept on a single server system and read by individual computers during the installation. This installation method can support the use of a single kickstart file to install Red Hat Enterprise Linux on multiple machines, making it ideal for network and system administrators. Kickstart provides a way for users to automate a Red Hat Enterprise Linux installation. All kickstart scriptlets and the log files of their execution are stored in the /tmp directory to assist with debugging installation failures. Note Anaconda now configures network interfaces with NetworkManager . Consequently, kickstart users that referenced the network settings located in /tmp/netinfo in versions of Red Hat Enterprise Linux must now source the ifcfg files in /etc/sysconfig/network-scripts .

Commands:
4. Storage LVM Snapshots of Mirrors The LVM snapshot feature provides the ability to create backup images of a logical volume at a particular instant without causing a service interruption. When a change is made to the original device (the origin) after a snapshot is taken, the snapshot feature makes a copy of the changed data area as it was prior to the change so that it can reconstruct the state of the device. In Red Hat Enterprise Linux 6.1 the ability to take a snapshot of a mirrored logical volume is a fully supported feature. LVM Stripe of Mirrors It is now possible to combine RAID0 (striping) and RAID1 (mirroring) in a single logical volume in LVM. Creating a logical volume while simultaneously specifying the number of mirrors ('--mirrors X') and the number of stripes ('--stripes Y') results in a mirror devices whose constituent devices are striped.

Commands:
8.85. ledmon 8.85.1. RHBA-2013:1722 - ledmon bug fix and enhancement update Updated ledmon packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The ledmon and ledctl utilities are user-space applications designed to control LEDs associated with each slot in an enclosure or a drive bay. There are two types of systems: 2-LED system (Activity LED, Status LED) and 3-LED system (Activity LED, Locate LED, Fail LED). Users must have root privileges to use this application. Note The ledmon packages have been upgraded to upstream version 0.78, which provides a number of bug fixes and enhancements over the version. (BZ# 922976 , BZ# 876593 , BZ# 887370 ) Users of ledmon are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands: