mtpti5iD/redhat-docs_dataset huggingface dataset:
40.6. Understanding /dev/oprofile/ The /dev/oprofile/ directory contains the file system for OProfile. Use the cat command to display the values of the virtual files in this file system. For example, the following command displays the type of processor OProfile detected: A directory exists in /dev/oprofile/ for each counter. For example, if there are 2 counters, the directories /dev/oprofile/0/ and dev/oprofile/1/ exist. Each directory for a counter contains the following files: count - The interval between samples. enabled - If 0, the counter is off and no samples are collected for it; if 1, the counter is on and samples are being collected for it. event - The event to monitor. kernel - If 0, samples are not collected for this counter event when the processor is in kernel-space; if 1, samples are collected even if the processor is in kernel-space. unit_mask - Defines which unit masks are enabled for the counter. user - If 0, samples are not collected for the counter event when the processor is in user-space; if 1, samples are collected even if the processor is in user-space. The values of these files can be retrieved with the cat command. For example:

Commands:
cat /dev/oprofile/cpu_type
cat /dev/oprofile/0/count
Chapter 14. Uninstalling a cluster on Azure You can remove a cluster that you deployed to Microsoft Azure. 14.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. 14.2. Deleting Microsoft Azure resources with the Cloud Credential Operator utility After uninstalling an OpenShift Container Platform cluster that uses short-term credentials managed outside the cluster, you can use the CCO utility ( ccoctl ) to remove the Microsoft Azure (Azure) resources that ccoctl created during installation. Prerequisites Extract and prepare the ccoctl binary. Uninstall an OpenShift Container Platform cluster on Azure that uses short-term credentials. Procedure Delete the Azure resources that ccoctl created by running the following command: USD ccoctl azure delete \ --name=<name> \ 1 --region=<azure_region> \ 2 --subscription-id=<azure_subscription_id> \ 3 --delete-oidc-resource-group 1 <name> matches the name that was originally used to create and tag the cloud resources. 2 <azure_region> is the Azure region in which to delete cloud resources. 3 <azure_subscription_id> is the Azure subscription ID for which to delete cloud resources. Verification To verify that the resources are deleted, query Azure. For more information, refer to Azure documentation.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
ccoctl azure delete --name=<name> \ 1 --region=<azure_region> \ 2 --subscription-id=<azure_subscription_id> \ 3 --delete-oidc-resource-group
probe::netfilter.ip.pre_routing Name probe::netfilter.ip.pre_routing - Called before an IP packet is routed Synopsis netfilter.ip.pre_routing Values indev Address of net_device representing input device, 0 if unknown nf_drop Constant used to signify a 'drop' verdict daddr A string representing the destination IP address pf Protocol family - either 'ipv4' or 'ipv6' sport TCP or UDP source port (ipv4 only) saddr A string representing the source IP address 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) iphdr Address of IP header fin TCP FIN flag (if protocol is TCP; ipv4 only) dport TCP or UDP destination port (ipv4 only) nf_queue Constant used to signify a 'queue' verdict nf_stop Constant used to signify a 'stop' verdict rst TCP RST flag (if protocol is TCP; ipv4 only) protocol Packet protocol from driver (ipv4 only) outdev_name Name of network device packet will be routed to (if known) nf_accept Constant used to signify an 'accept' verdict indev_name Name of network device packet was received on (if known) ipproto_tcp Constant used to signify that the packet protocol is TCP family IP address family nf_repeat Constant used to signify a 'repeat' verdict outdev Address of net_device representing output device, 0 if unknown psh TCP PSH flag (if protocol is TCP; ipv4 only) urg TCP URG flag (if protocol is TCP; ipv4 only) length The length of the packet buffer contents, in bytes nf_stolen Constant used to signify a 'stolen' verdict

Commands:
Chapter 35. Viewing preemption states Processes using a CPU can give up the CPU they are using, either voluntarily or involuntarily. 35.1. Preemption A process can voluntarily yield the CPU either because it has completed, or because it is waiting for an event, such as data from a disk, a key press, or for a network packet. A process can also involuntarily yield the CPU. This is called preemption and occurs when a higher priority process wants to use the CPU. Preemption can have a particularly negative impact on system performance, and constant preemption can lead to a state known as thrashing. This problem occurs when processes are constantly preempted, and no process ever runs to completion. Changing the priority of a task can help reduce involuntary preemption. 35.2. Checking the preemption state of a process You can check the voluntary and involuntary preemption status for a specified process. The statuses are stored in /proc/ PID /status . Prerequisites You have administrator privileges. Procedure Display the contents of /proc/ PID /status , where PID is the ID of the process. The following displays the preemption statuses for the process with PID 1000.

Commands:
grep voluntary /proc/1000/status voluntary_ctxt_switches: 194529 nonvoluntary_ctxt_switches: 195338
Chapter 14. Red Hat Decision Manager Red Hat build of Kogito Operator interaction with Kafka The Red Hat Decision Manager Red Hat build of Kogito Operator uses the AMQ Streams Operator to automatically configure the Red Hat build of Kogito microservice with Kafka. When you enable an infrastructure mechanism through KogitoInfra deployment, the Red Hat Decision Manager Red Hat build of Kogito Operator uses the relevant third-party operator to configure the infrastructure. You must define your custom infrastructure resource and link it in the KogitoInfra file. You can specify your custom infrastructure resource in the spec.resource.name and spec.resource.namespace configurations. Example Red Hat Decision Manager Red Hat build of Kogito infrastructure resource for custom messaging apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoInfra # Application type metadata: name: my-kafka-infra spec: resource: apiVersion: kafka.strimzi.io/v1beta2 # AMQ Streams API kind: Kafka # AMQ Streams Application Type name: my-kafka-instance namespace: my-namespace In this example, the KogitoInfra custom resource connects to the Kafka cluster my-kafka-instance from my-namespace for event messaging. To connect Red Hat build of Kogito microservice to Kafka, you need to define the infra configuration to use the corresponding infrastructure. Example of Red Hat build of Kogito microservice resource configuration with messaging apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoRuntime # Application type metadata: name: example-quarkus # Application name spec: image: <final-image-name> # Kogito image name insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate infra: - my-kafka-infra The Red Hat Decision Manager Red Hat build of Kogito Operator configures the necessary properties so that your application can connect to the Kafka instance.

Commands:
apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoInfra # Application type metadata: name: my-kafka-infra spec: resource: apiVersion: kafka.strimzi.io/v1beta2 # AMQ Streams API kind: Kafka # AMQ Streams Application Type name: my-kafka-instance namespace: my-namespace
apiVersion: rhpam.kiegroup.org/v1 # Red Hat build of Kogito API for this microservice kind: KogitoRuntime # Application type metadata: name: example-quarkus # Application name spec: image: <final-image-name> # Kogito image name insecureImageRegistry: true # Can be omitted when image is pushed into secured registry with valid certificate infra: - my-kafka-infra
Chapter 3. Accessing the Red Hat Support If you require help with troubleshooting a problem, you can contact Red Hat Support. Procedure Log in to the Red Hat Support web site and choose one of the following options: Open a new support case. Initiate a live chat with a Red Hat expert. Contact a Red Hat expert by making a call or sending an email. 3.1. Using the sosreport utility to collect daignostic information about a system to attach it to a support ticket The sosreport command collects configuration details, system information and diagnostic information from a Red Hat Enterprise Linux system. The following section describes how to use the sosreport command to produce reports for your support cases. Prerequisites A valid user account on the Red Hat Customer Portal. See Create a Red Hat Login . An active subscription for the RHEL system. A support-case number. Procedure Install the sos package: Generate a report: Optionally, pass the -upload option to the command to automatically upload and attach the report to a support case. This requires internet access and your Customer Portal credentials. Optional: Manually attach the report to your support case. See the Red Hat Knowledgebase solution How can I attach a file to a Red Hat support case? for more information. Additional resources What is an sosreport and how to create one in Red Hat Enterprise Linux? (Red Hat Knowledgebase)

Commands:
yum install sos
sosreport
Preface Red Hat Developer Hub (RHDH) is an enterprise-grade internal developer portal designed to simplify and streamline software development processes. Combined with Red Hat OpenShift Container Platform, RHDH empowers platform engineering teams to create customized portals that improve developer productivity, accelerate onboarding, and enable faster application delivery. By reducing friction and complexity, RHDH allows developers to focus on writing high-quality code while adhering to enterprise-class best practices. RHDH integrates software templates, pre-designed solutions, and dynamic plugins into a centralized platform, providing tailored solutions for operations and development teams in a unified environment.

Commands:
4.194. newt 4.194.1. RHEA-2011:1207 - newt enhancement update Updated newt packages that add one enhancement are now available for Red Hat Enterprise Linux 6. Newt is a programming library for color text mode, widget-based user interfaces. Newt can be used to add stacked windows, entry widgets, check boxes, radio buttons, labels, plain text fields, and so on, to text mode user interfaces. Enhancement BZ# 707704 Prior to this update, it was not possible to set a color of individual labels, scrollbars, entries, textboxes, and scales. With this update, setting a color of the aforementioned GUI elements is now possible. All users of newt are advised to upgrade to these updated packages, which add this enhancement.

Commands:
Chapter 11. rsync The rsync utility performs fast file transfer and it is used for synchronizing data between systems. [9] When using Red Hat Enterprise Linux, the rsync package provides rsync . Run the rpm -q rsync command to see if the rsync package is installed. If it is not installed, run the following command as the root user to install it: 11.1. rsync and SELinux SELinux requires files to have an extended attribute to define the file type. Policy governs the access daemons have to these files. If you want to share files using the rsync daemon, you must label the files and directories with the public_content_t type. Like most services, correct labeling is required for SELinux to perform its protection mechanisms over rsync . [10] [9] Refer to the Rsync project page for more information. [10] Refer to the rsync_selinux (8) manual page for more information about rsync and SELinux.

Commands:
~]# yum install rsync
6.10. Revocation Routing Configuration To configure revocation routing, you must first define a list of relevant CA connectors and add them to the connector list in the following format: Additionally, you must add the CA signing certificate to the TPS nssdb and set up trust: Finally, the nickname of the CA signing certificate must be added to the connector using the following option: Note During CA discovery, the TPS may automatically calculate the Authority Key Identifier of the CA and add it to the connector configuration. For example: This behavior is expected.

Commands:
tps.connCAList=ca1,ca2
cd <TPS instance directory> /alias
certutil -d . -A -n <CA signing cert nickname> -t "CT,C,C" -i <CA signing cert b64 file name>
tps.connector.ca1.caNickname=caSigningCert cert-pki-tomcat CA
tps.connector.ca1.caSKI=i9wOnN0QZLkzkndAB1MKMcjbRP8=
4.5. Examples of Using Tuna Example 4.1. Assigning Tasks to Specific CPUs The following example uses a system with four or more processors, and shows how to make all ssh threads run on CPU 0 and 1, and all http threads on CPU 2 and 3. The above example command performs the following operations sequentially: Select CPUs 0 and 1. Select all threads that begin with ssh . Move the selected threads to the selected CPUs. Tuna sets the affinity mask of threads starting with ssh to the appropriate CPUs. The CPUs can be expressed numerically as 0 and 1, in hex mask as 0x3 , or in binary as 11 . Reset the CPU list to 2 and 3. Select all threads that begin with http . Move the selected threads to the selected CPUs. Tuna sets the affinity mask of threads starting with http to the appropriate CPUs. The CPUs can be expressed numerically as 2 and 3, in hex mask as 0xC , or in binary as 1100 . Example 4.2. Viewing Current Configurations The following example uses the --show_threads ( -P ) parameter to display the current configuration, and then tests if the requested changes were made as expected. The above example command performs the following operations sequentially: Select all threads that begin with gnome-sc . Show the selected threads to enable the user to verify their affinity mask and RT priority. Select CPU 0. Move the gnome-sc threads to the selected CPU (CPU 0). Show the result of the move. Reset the CPU list to CPU 1. Move the gnome-sc threads to the selected CPU (CPU 1). Show the result of the move. Add CPU 0 to the CPU list. Move the gnome-sc threads to the selected CPUs (CPUs 0 and 1). Show the result of the move.

Commands:
tuna --cpus=0,1 --threads=ssh\* --move --cpus=2,3 --threads=http\* --move
tuna --threads=gnome-sc\* --show_threads --cpus=0 --move --show_threads --cpus=1 --move --show_threads --cpus=+0 --move --show_threads thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 0,1 33997 58 gnome-screensav thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 0 33997 58 gnome-screensav thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 1 33997 58 gnome-screensav thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3861 OTHER 0 0,1 33997 58 gnome-screensav
8.3.5. Saving SCAP Content SCAP Workbench also allows you to save SCAP content that is used with your system evaluations. You can either save a customization file separately (see Section 8.3.4, "Customizing Security Profiles" ) or you can save all security content at once by clicking the Save content combo box and selecting either the Save into a directory or Save as RPM options. By selecting the Save into a directory option, SCAP Workbench saves both the XCCDF or data-stream file and the customization file to the specified location. This can be useful as a backup solution. By selecting the Save as RPM option, you can instruct SCAP Workbench to create an RPM package containing the XCCDF or data stream file and customization file. This is useful for distributing the desired security content to systems that cannot be scanned remotely, or just for delivering the content for further processing. Figure 8.6. Saving the Current SCAP Content as an RPM Package

Commands:
7.2. Configuration changes As well as configuring libvirt appropriately, virt-v2v will make certain changes to a virtual machine to enable it to run on a KVM hypervisor either with or without virtIO drivers. These changes are specific to the guest operating system. The details specified here apply to supported Red Hat Enterprise Linux versions and Windows. 7.2.1. Configuration changes for Linux virtual machines Table 7.1. virt-v2v changes to Linux virtual machines Change Description Kernel Unbootable kernels (such as Xen paravirtualized kernels) will be uninstalled. No new kernel will be installed if there is a remaining kernel which supports VirtIO. If no remaining kernel supports VirtIO and the configuration file specifies a new kernel it will be installed and configured as the default. X reconfiguration If the guest has X configured, its display driver will be updated. See Table 7.2, "Configured drivers in a Linux guest" for which driver will be used. Rename block devices If reconfiguration has caused block devices to change name, these changes will be reflected in /etc/fstab . Configure device drivers Whether VirtIO or non-VirtIO drivers are configured, virt-v2v will ensure that the correct network and block drivers are specified in the modprobe configuration. initrd virt-v2v will ensure that the initrd for the default kernel supports booting the root device, whether it is using VirtIO or not. SELinux virt-v2v will initiate a relabel of the guest on the boot. This ensures that any changes it has made are correctly labeled according to the guest's local policy. virt-v2v will configure the following drivers in a Linux guest: Table 7.2. Configured drivers in a Linux guest Paravirtualized driver type Driver module Display cirrus Storage virtio_blk Network virtio_net In addition, initrd will preload the virtio_pci driver Table 7.2. Configured drivers in a Linux guest Other drivers Display cirrus Block Virtualized IDE Network Virtualized e1000

Commands:
Chapter 67. JmxTransSpec schema reference The type JmxTransSpec has been deprecated. Used in: KafkaSpec Property Property type Description image string The image to use for the JmxTrans. outputDefinitions JmxTransOutputDefinitionTemplate array Defines the output hosts that will be referenced later on. For more information on these properties see, JmxTransOutputDefinitionTemplate schema reference . logLevel string Sets the logging level of the JmxTrans deployment.For more information see, JmxTrans Logging Level . kafkaQueries JmxTransQueryTemplate array Queries to send to the Kafka brokers to define what data should be read from each broker. For more information on these properties see, JmxTransQueryTemplate schema reference . resources ResourceRequirements CPU and memory resources to reserve. template JmxTransTemplate Template for JmxTrans resources.

Commands:
10.5.14. IfDefine The IfDefine tags surround configuration directives that are applied if the "test" stated in the IfDefine tag is true. The directives are ignored if the test is false. The test in the IfDefine tags is a parameter name (for example, HAVE_PERL ). If the parameter is defined, meaning that it is provided as an argument to the server's start-up command, then the test is true. In this case, when the Web server is started, the test is true and the directives contained in the IfDefine tags are applied.

Commands:
Chapter 7. Configuring SSSD 7.1. Introduction to SSSD 7.1.1. How SSSD Works The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. It connects a local system (an SSSD client ) to an external back-end system (a provider ). This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, these remote services include: an LDAP directory, an Identity Management (IdM) or Active Directory (AD) domain, or a Kerberos realm. For this purpose, SSSD: Connects the client to an identity store to retrieve authentication information. Uses the obtained authentication information to create a local cache of users and credentials on the client. Users on the local system are then able to authenticate using the user accounts stored in the external back-end system. SSSD does not create user accounts on the local system. Instead, it uses the identities from the external data store and lets the users access the local system. Figure 7.1. How SSSD works SSSD can also provide caches for several system services, such as Name Service Switch (NSS) or Pluggable Authentication Modules (PAM). 7.1.2. Benefits of Using SSSD Reduced load on identity and authentication servers When requesting information, SSSD clients contact SSSD, which checks its cache. SSSD contacts the servers only if the information is not available in the cache. Offline authentication SSSD optionally keeps a cache of user identities and credentials retrieved from remote services. In this setup, users can successfully authenticate to resources even if the remote server or the SSSD client are offline. A single user account: improved consistency of the authentication process With SSSD, it is not necessary to maintain both a central account and a local user account for offline authentication. Remote users often have multiple user accounts. For example, to connect to a virtual private network (VPN), remote users have one account for the local system and another account for the VPN system. Thanks to caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine. SSSD then maintains their network credentials.

Commands:
2.2.2.4. Script Changes These changes affect the use of %pre , %post and %traceback scripts. Logging of errors while running scripts has been improved. Scripts are no longer removed after they are run, so they can be inspected. This is most useful on systems where the scripts are dynamically generated so you can see what was run. In addition, the stderr and stdout output is always logged for every script. This has one important side effect: if your scripts use an interactive program, you must pass --logfile=/dev/tty3 to the header of your scripts. Otherwise, you will not be able to interact with the program.

Commands: