mtpti5iD/redhat-docs_dataset huggingface dataset:
15.2. Removing Swap Space Sometimes it can be prudent to reduce swap space after installation. For example, say you 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: Enable the extended logical volume: To test if the swap's logical volume size was successfully reduced, use cat /proc/swaps or free to inspect the swap space.

Commands:
swapoff -v /dev/VolGroup00/LogVol01
lvreduce /dev/VolGroup00/LogVol01 -L -512M
mkswap /dev/VolGroup00/LogVol01
swapon -v /dev/VolGroup00/LogVol01
9.2. Configuring Publishing to a File The general process to configure publishing involves setting up a publisher to publish the certificates or CRLs to the specific location. There can be a single publisher or multiple publishers, depending on how many locations will be used. The locations can be split by certificates and CRLs or finer definitions, such as certificate type. Rules determine which type to publish and to what location by being associated with the publisher. Publishing to file simply publishes the CRLs or certificates to text files on a given host. Publishers must be created and configured for each publishing location; publishers are not automatically created for publishing to a file. To publish all files to a single location, create one publisher. To publish to different locations, create a publisher for each location. A location can either contain an object type, like user certificates, or a subset of an object type, like West Coast user certificates. To create publishers for publishing to files: Log into the Certificate Manager Console. In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing , and then Publishers . The Publishers Management tab, which lists configured publisher instances, opens on the right. Click Add to open the Select Publisher Plug-in Implementation window, which lists registered publisher modules. Select the FileBasedPublisher module, then open the editor window. This is the module that enables the Certificate Manager to publish certificates and CRLs to files. Configure the information for publishing the certificate: The publisher ID, an alphanumeric string with no spaces like PublishCertsToFile The path to the directory in which the Certificate Manager should publish the files. The path can be an absolute path or can be relative to the Certificate System instance directory. For example, /export/CS/certificates . The file type to publish, by selecting the checkboxes for DER-encoded files, base-64 encoded files, or both. For CRLs, the format of the timestamp. Published certificates include serial numbers in their file names, while CRLs use timestamps. For CRLs, whether to generate a link in the file to go to the latest CRL. If enabled, the link assumes that the name of the CRL issuing point to use with the extension will be supplied in the crlLinkExt field. For CRLs, whether to compress (zip) CRLs and the compression level to use. After configuring the publisher, configure the rules for the published certificates and CRLs, as described in Section 9.5, "Creating Rules" . Note pkiconsole is being deprecated.

Commands:
pkiconsole https://server.example.com:8443/ca
Chapter 12. Scaling Multicloud Object Gateway performance The Multicloud Object Gateway (MCG) performance may vary from one environment to another. In some cases, specific applications require faster performance which can be easily addressed by scaling S3 endpoints. The MCG resource pool is a group of NooBaa daemon containers that provide two types of services enabled by default: Storage service S3 endpoint service S3 endpoint service The S3 endpoint is a service that every Multicloud Object Gateway (MCG) provides by default that handles the heavy lifting data digestion in the MCG. The endpoint service handles the inline data chunking, deduplication, compression, and encryption, and it accepts data placement instructions from the MCG. 12.1. Automatic scaling of MultiCloud Object Gateway endpoints The number of MultiCloud Object Gateway (MCG) endpoints scale automatically when the load on the MCG S3 service increases or decreases. OpenShift Data Foundation clusters are deployed with one active MCG endpoint. Each MCG endpoint pod is configured by default with 1 CPU and 2Gi memory request, with limits matching the request. When the CPU load on the endpoint crosses over an 80% usage threshold for a consistent period of time, a second endpoint is deployed lowering the load on the first endpoint. When the average CPU load on both endpoints falls below the 80% threshold for a consistent period of time, one of the endpoints is deleted. This feature improves performance and serviceability of the MCG. You can scale the Horizontal Pod Autoscaler (HPA) for noobaa-endpoint using the following oc patch command, for example: The example above sets the minCount to 3 and the maxCount to `10 . 12.2. Increasing CPU and memory for PV pool resources MCG default configuration supports low resource consumption. However, when you need to increase CPU and memory to accommodate specific workloads and to increase MCG performance for the workloads, you can configure the required values for CPU and memory in the OpenShift Web Console. Procedure In the OpenShift Web Console, navigate to Storage Object Storage Backing Store . Select the relevant backing store and click on YAML. Scroll down until you find spec: and update pvPool with CPU and memory. Add a new property of limits and then add cpu and memory. Example reference: Click Save . Verification steps To verfiy, you can check the resource values of the PV pool pods.

Commands:
oc patch -n openshift-storage storagecluster ocs-storagecluster --type merge --patch '{"spec": {"multiCloudGateway": {"endpoints": {"minCount": 3,"maxCount": 10}}}}'
spec: pvPool: resources: limits: cpu: 1000m memory: 4000Mi requests: cpu: 800m memory: 800Mi storage: 50Gi
Chapter 5. Adding administrative users Before you can install and configure OpenShift AI for your data scientist users, you must define administrative users. Only administrative users can install and configure OpenShift AI. Prerequisites Credentials for OpenShift Cluster Manager ( https://console.redhat.com/openshift/ ). An existing OpenShift Dedicated or Red Hat OpenShift Service on AWS (ROSA) cluster with an identity provider configured. Procedure Log in to OpenShift Cluster Manager ( https://console.redhat.com/openshift/ ). Click Clusters . The Clusters page opens. Click the name of the cluster to configure. Click the Access control tab. Click Cluster Roles and Access . Under Cluster administrative users click the Add user button. The Add cluster user popover appears. Enter the user name in the User ID field. Select an appropriate Group for the user. Important If this user needs to use existing groups in an identity provider to control OpenShift AI access, select cluster-admins . For more information about these user types, see Managing administration roles and users in the OpenShift Dedicated documentation or Default cluster roles in the ROSA documentation. Click Add user . Verification The user name and selected group are visible in the list of Cluster administrative users . Additional resources OpenShift Dedicated Cluster administration ROSA Cluster administration

Commands:
Chapter 3. Running functions locally You can run a function locally by using the kn func tool. This can be useful, for example, for testing the function before deploying it to the cluster. 3.1. Running a function locally You can use the kn func run command to run a function locally in the current directory or in the directory specified by the --path flag. If the function that you are running has never previously been built, or if the project files have been modified since the last time it was built, the kn func run command builds the function before running it by default. Example command to run a function in the current directory USD kn func run Example command to run a function in a directory specified as a path USD kn func run --path=<directory_path> You can also force a rebuild of an existing image before running the function, even if there have been no changes to the project files, by using the --build flag: Example run command using the build flag USD kn func run --build If you set the build flag as false, this disables building of the image, and runs the function using the previously built image: Example run command using the build flag USD kn func run --build=false You can use the help command to learn more about kn func run command options: Build help command USD kn func help run

Commands:
kn func run
kn func run --path=<directory_path>
kn func run --build
kn func run --build=false
kn func help run
1.5. Configuring Red Hat High Availability Add-On Software Configuring Red Hat High Availability Add-On software consists of using configuration tools to specify the relationship among the cluster components. The following cluster configuration tools are available with Red Hat High Availability Add-On: Conga - This is a comprehensive user interface for installing, configuring, and managing Red Hat High Availability Add-On. Refer to Chapter 4, Configuring Red Hat High Availability Add-On With Conga and Chapter 5, Managing Red Hat High Availability Add-On With Conga for information about configuring and managing High Availability Add-On with Conga . The ccs command - This command configures and manages Red Hat High Availability Add-On. Refer to Chapter 6, Configuring Red Hat High Availability Add-On With the ccs Command and Chapter 7, Managing Red Hat High Availability Add-On With ccs for information about configuring and managing High Availability Add-On with the ccs command. Command-line tools - This is a set of command-line tools for configuring and managing Red Hat High Availability Add-On. Refer to Chapter 8, Configuring Red Hat High Availability Manually and Chapter 9, Managing Red Hat High Availability Add-On With Command Line Tools for information about configuring and managing a cluster with command-line tools. Refer to Appendix E, Command Line Tools Summary for a summary of preferred command-line tools. Note system-config-cluster is not available in Red Hat Enterprise Linux 6.

Commands:
Chapter 3. Installing and configuring the Datadog agent for Ceph Install the Datadog agent for Ceph and configure it to report back the Ceph data to the Datadog App. Prerequisites Root-level access to the Ceph monitor node. Appropriate Ceph key providing access to the Red Hat Ceph Storage cluster. Internet access. Procedure Log in to the Datadog App . The user interface will present navigation on the left side of the screen. Click Integrations . To install the agent from the command line, click on the Agent tab at the top of the screen. Open a command line and enter the one-step command line agent installation. Example Note Copy the example from the Datadog user interface, as the key differs from the example above and with each user account.

Commands:
DD_API_KEY= KEY-STRING bash -c "USD(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)"
F.5. Shutting Down To shut down Red Hat Enterprise Linux, the root user may issue the /sbin/shutdown command. The shutdown man page has a complete list of options, but the two most common uses are: and After shutting everything down, the -h option halts the machine, and the -r option reboots. PAM console users can use the reboot and halt commands to shut down the system while in runlevels 1 through 5. For more information about PAM console users, refer to the Red Hat Enterprise Linux Deployment Guide . If the computer does not power itself down, be careful not to turn off the computer until a message appears indicating that the system is halted. Failure to wait for this message can mean that not all the hard drive partitions are unmounted, which can lead to file system corruption.

Commands:
/sbin/shutdown -h now
/sbin/shutdown -r now
4.3. Tuning IRQs with Tuna To see the list of IRQs currently running on your system, see the Monitoring tab in Tuna GUI or the /proc/interrpupts file. You can also use the tuna --show_irqs command. To specify the list of IRQs to be affected by your command, use the --irqs parameter: To move an interrupt to a specified CPU, use the --move parameter: The irq_list argument is a list of comma-separated IRQ numbers or user-name patterns. The cpu_list argument is a list of comma-separated CPU numbers. For example, --cpus=0,2 . For example, to target all interrupts whose names start with sfc1 and spread them over two CPUs: To verify the changes you set, use the --show_irqs parameter both before and after modifying the IRQs with the --move parameter: This allows you to compare the state of the selected IRQs before and after your changes. Note Using the Tuna GUI might be more convenient in certain scenarios. Moving IRQs and threads by specifying the CPUs they are to run on can be time-consuming and difficult because it involves multiple steps of creating CPU masks. The Tuna GUI automates the process. In the Tuna GUI, you can also select threads and IRQs and drag them over the intended CPUs, which can make changing the topology easier.

Commands:
tuna --irqs= irq_list --run= COMMAND
tuna --irqs= irq_list --cpus= cpu_list --move
tuna --irqs=sfc1\* --cpus=7,8 --move --spread
tuna --irqs=128 --show_irqs # users affinity 128 iwlwifi 0,1,2,3 # tuna --irqs=128 --cpus=3 --move # tuna --irqs=128 --show_irqs # users affinity 128 iwlwifi 3
Chapter 28. References The following references are pointers to additional information that is relevant to SELinux but beyond the scope of this guide. Note that due to the rapid development of SELinux, some of this material may only apply to specific releases of Red Hat Enterprise Linux. Books SELinux by Example Mayer, MacMillan, and Caplan Prentice Hall, 2007 SELinux: NSA's Open Source Security Enhanced Linux Bill McCarty O'Reilly Media Inc., 2004 Tutorials and Help Tutorials and talks from Russell Coker http://www.coker.com.au/selinux/talks/ibmtu-2004/ Dan Walsh's Journal http://danwalsh.livejournal.com/ Red Hat Knowledgebase https://access.redhat.com/site/ Mailing Lists Fedora SELinux mailing list http://www.redhat.com/mailman/listinfo/fedora-selinux-list Community SELinux Project Wiki http://selinuxproject.org/page/Main_Page SELinux community page http://selinux.sourceforge.net/ IRC irc.freenode.net, #selinux

Commands:
6.5. Replacing a Missing Physical Volume If a physical volume fails or otherwise needs to be replaced, you can label a new physical volume to replace the one that has been lost in the existing volume group by following the same procedure as you would for recovering physical volume metadata, described in Section 6.4, "Recovering Physical Volume Metadata" . You can use the --partial and --verbose arguments of the vgdisplay command to display the UUIDs and sizes of any physical volumes that are no longer present. If you wish to substitute another physical volume of the same size, you can use the pvcreate command with the --restorefile and --uuid arguments to initialize a new device with the same UUID as the missing physical volume. You can then use the vgcfgrestore command to restore the volume group's metadata.

Commands:
5.17. Configuring Logging for Denied Packets With the LogDenied option in the firewalld , it is possible to add a simple logging mechanism for denied packets. These are the packets that are rejected or dropped. To change the setting of the logging, edit the /etc/firewalld/firewalld.conf file or use the command-line or GUI configuration tool. If LogDenied is enabled, logging rules are added right before the reject and drop rules in the INPUT, FORWARD and OUTPUT chains for the default rules and also the final reject and drop rules in zones. The possible values for this setting are: all , unicast , broadcast , multicast , and off . The default setting is off . With the unicast , broadcast , and multicast setting, the pkttype match is used to match the link-layer packet type. With all , all packets are logged. To list the actual LogDenied setting with firewall-cmd, use the following command as root : To change the LogDenied setting, use the following command as root : To change the LogDenied setting with the firewalld GUI configuration tool, start firewall-config , click the Options menu and select Change Log Denied . The LogDenied window appears. Select the new LogDenied setting from the menu and click OK.

Commands:
~]# firewall-cmd --get-log-denied off
~]# firewall-cmd --set-log-denied= all success
3.4. Running converted virtual machines On successful completion, virt-v2v will create a new libvirt domain for the converted virtual machine with the same name as the original virtual machine. It can be started as usual using libvirt tools, for example virt-manager . Note virt-v2v cannot currently reconfigure a virtual machine's network configuration. If the converted virtual machine is not connected to the same subnet as the source, the virtual machine's network configuration may have to be updated manually.

Commands:
Chapter 4. Power Management 4.1. Introduction to Power Management and Fencing The Red Hat Virtualization environment is most flexible and resilient when power management and fencing have been configured. Power management allows the Red Hat Virtualization Manager to control host power cycle operations, most importantly to reboot hosts on which problems have been detected. Fencing is used to isolate problem hosts from a functional Red Hat Virtualization environment by rebooting them, in order to prevent performance degradation. Fenced hosts can then be returned to responsive status through administrator action and be reintegrated into the environment. Power management and fencing make use of special dedicated hardware in order to restart hosts independently of host operating systems. The Red Hat Virtualization Manager connects to a power management devices using a network IP address or hostname. In the context of Red Hat Virtualization, a power management device and a fencing device are the same thing.

Commands:
Chapter 125. KafkaUserTemplate schema reference Used in: KafkaUserSpec Full list of KafkaUserTemplate schema properties Specify additional labels and annotations for the secret created by the User Operator. An example showing the KafkaUserTemplate apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: type: tls template: secret: metadata: labels: label1: value1 annotations: anno1: value1 # ... 125.1. KafkaUserTemplate schema properties Property Property type Description secret ResourceTemplate Template for KafkaUser resources. The template allows users to specify how the Secret with password or TLS certificates is generated.

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster spec: authentication: type: tls template: secret: metadata: labels: label1: value1 annotations: anno1: value1 #
Chapter 12. Removing the trust using the command line You can remove the Identity Management (IdM)/Active Directory (AD) trust on the IdM side using the command line. Prerequisites You have obtained a Kerberos ticket as an IdM administrator. For details, see Logging in to IdM in the Web UI: Using a Kerberos ticket . Procedure Use the ipa trust-del command to remove the trust configuration from IdM. Remove the trust object from your Active Directory configuration. Note Removing the trust configuration does not automatically remove the ID range IdM has created for AD users. This way, if you add the trust again, the existing ID range is re-used. Also, if AD users have created files on an IdM client, their POSIX IDs are preserved in the file metadata. To remove all information related to an AD trust, remove the AD user ID range after removing the trust configuration and trust object: Verification Use the ipa trust-show command to confirm that the trust has been removed.

Commands:
ipa trust-del ad_domain_name ------------------------------ Deleted trust " ad_domain_name " ------------------------------
ipa idrange-del AD.EXAMPLE.COM_id_range systemctl restart sssd
ipa trust-show ad.example.com ipa: ERROR: ad.example.com: trust not found
Chapter 2. Streams for Apache Kafka deployment of Kafka Streams for Apache Kafka enables the deployment of Apache Kafka components to an OpenShift cluster, typically running as clusters for high availability. A standard Kafka deployment using Streams for Apache Kafka might include the following components: Kafka cluster of broker nodes as the core component Kafka Connect cluster for external data connections Kafka MirrorMaker cluster to mirror data to another Kafka cluster Kafka Exporter to extract additional Kafka metrics data for monitoring Kafka Bridge to enable HTTP-based communication with Kafka Cruise Control to rebalance topic partitions across brokers Not all of these components are required, though you need Kafka as a minimum for a Streams for Apache Kafka-managed Kafka cluster. Depending on your use case, you can deploy the additional components as needed. These components can also be used with Kafka clusters that are not managed by Streams for Apache Kafka. 2.1. Kafka component architecture A KRaft-based Kafka cluster consists of broker nodes responsible for message delivery and controller nodes that manage cluster metadata and coordinate clusters. These roles can be configured using node pools in Streams for Apache Kafka. Other Kafka components interact with the Kafka cluster for specific tasks. Kafka component interaction Kafka Connect Kafka Connect is an integration toolkit for streaming data between Kafka brokers and other systems using connector plugins. Kafka Connect provides a framework for integrating Kafka with an external data source or target, such as a database, for import or export of data using connectors. Connectors provide the connection configuration needed. A source connector pushes external data into Kafka. A sink connector extracts data out of Kafka External data is translated and transformed into the appropriate format. Kafka Connect can be configured to build custom container images with the required connectors. Kafka MirrorMaker Kafka MirrorMaker replicates data between two Kafka clusters, either in the same data center or across different locations. Kafka Bridge Kafka Bridge provides an API for integrating HTTP-based clients with a Kafka cluster. Kafka Exporter Kafka Exporter extracts data for analysis as Prometheus metrics, primarily data relating to offsets, consumer groups, consumer lag and topics. Consumer lag is the delay between the last message written to a partition and the message currently being picked up from that partition by a consumer Apache ZooKeeper (optional) Apache ZooKeeper provides a cluster coordination service, storing and tracking the status of brokers and consumers. ZooKeeper is also used for controller election. If ZooKeeper is used, the ZooKeeper cluster must be ready before running Kafka. However, since the introduction of KRaft, ZooKeeper is no longer required as Kafka nodes handle cluster coordination and control natively.

Commands: