mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 36. Setting the priority for a process with the chrt utility You can set the priority for a process using the chrt utility. Prerequisites You have administrator privileges. 36.1. Setting the process priority using the chrt utility The chrt utility checks and adjusts scheduler policies and priorities. It can start new processes with the desired properties, or change the properties of a running process. Procedure To set the scheduling policy of a process, run the chrt command with the appropriate command options and parameters. In the following example, the process ID affected by the command is 1000 , and the priority ( -p ) is 50 . To start an application with a specified scheduling policy and priority, add the name of the application, and the path to it, if necessary, along with the attributes. For more information about the chrt utility options, see The chrt utility options . 36.2. The chrt utility options The chrt utility options include command options and parameters specifying the process and priority for the command. Policy options -f Sets the scheduler policy to SCHED_FIFO . -o Sets the scheduler policy to SCHED_OTHER . -r Sets the scheduler policy to SCHED_RR (round robin). -d Sets the scheduler policy to SCHED_DEADLINE . -p n Sets the priority of the process to n . When setting a process to SCHED_DEADLINE, you must specify the runtime , deadline , and period parameters. For example: where --sched-runtime 5000000 is the run time in nanoseconds. --sched-deadline 10000000 is the relative deadline in nanoseconds. --sched-period 16666666 is the period in nanoseconds. 0 is a placeholder for unused priority required by the chrt command. 36.3. Additional resources chrt(1) man page on your system

Commands:
chrt -f -p 50 1000
chrt -r -p 50 /bin/my-app
chrt -d --sched-runtime 5000000 --sched-deadline 10000000 --sched-period 16666666 0 video_processing_tool
23.16. Timer Element Attributes The name element contains the name of the time source to be used. It can have any of the following values: Table 23.12. Name attribute values Value Description pit Programmable Interval Timer - a timer with periodic interrupts. When using this attribute, the tickpolicy delay becomes the default setting. rtc Real Time Clock - a continuously running timer with periodic interrupts. This attribute supports the tickpolicy catchup sub-element. kvmclock KVM clock - the recommended clock source for KVM guest virtual machines. KVM pvclock, or kvm-clock allows guest virtual machines to read the host physical machine's wall clock time. The track attribute specifies what is tracked by the timer, and is only valid for a name value of rtc . Table 23.13. track attribute values Value Description boot Corresponds to old host physical machine option, this is an unsupported tracking option. guest RTC always tracks the guest virtual machine time. wall RTC always tracks the host time. The tickpolicy attribute and the values dictate the policy that is used to pass ticks on to the guest virtual machine. Table 23.14. tickpolicy attribute values Value Description delay Continue to deliver at normal rate (ticks are delayed). catchup Deliver at a higher rate to catch up. merge Ticks merged into one single tick. discard All missed ticks are discarded. The present attribute is used to override the default set of timers visible to the guest virtual machine. The present attribute can take the following values: Table 23.15. present attribute values Value Description yes Force this timer to be visible to the guest virtual machine. no Force this timer to not be visible to the guest virtual machine.

Commands:
11.10. Additional Resources Installed Documentation udev(7) man page - Describes the Linux dynamic device management daemon, udevd . systemd(1) man page - Describes systemd system and service manager. biosdevname(1) man page - Describes the utility for obtaining the BIOS-given name of a device. Online Documentation The IBM Knowledge Center Publication SC34-2710-00 Device Drivers, Features, and Commands on Red Hat Enterprise Linux 7 includes information on " Predictable network device names " for IBM System z devices and attachments.

Commands:
8.4. Installing in the Graphical User Interface The graphical installation interface is the preferred method of manually installing Red Hat Enterprise Linux. It allows you full control over all available settings, including custom partitioning and advanced storage configuration, and it is also localized to many languages other than English, allowing you to perform the entire installation in a different language. The graphical mode is used by default when you boot the system from local media (a CD, DVD or a USB flash drive). Figure 8.2. The Installation Summary Screen The sections below discuss each screen available in the installation process. Note that due to the installer's parallel nature, most of the screens do not have to be completed in the order in which they are described here. Each screen in the graphical interface contains a Help button. This button opens the Yelp help browser displaying the section of the Red Hat Enterprise Linux Installation Guide relevant to the current screen. You can also control the graphical installer with your keyboard. Following table shows you the shortcuts you can use. Table 8.2. Graphical installer keyboard shortcuts Shortcut keys Usage Tab and Shift + Tab Cycle through active control elements (buttons, check boxes, and so on.) on the current screen Up and Down Scroll through lists Left and Right Scroll through horizontal toolbars and table entries Space and Enter Select or remove a highlighted item from selection and expand and collapse drop-down menus Additionally, elements in each screen can be toggled using their respective shortcuts. These shortcuts are highlighted (underlined) when you hold down the Alt key; to toggle that element, press Alt + X , where X is the highlighted letter. Your current keyboard layout is displayed in the top right hand corner. Only one layout is configured by default; if you configure more than layout in the Keyboard Layout screen ( Section 8.9, "Keyboard Configuration" ), you can switch between them by clicking the layout indicator.

Commands:
Chapter 4. KafkaSpec schema reference Used in: Kafka Property Property type Description kafka KafkaClusterSpec Configuration of the Kafka cluster. zookeeper ZookeeperClusterSpec Configuration of the ZooKeeper cluster. This section is required when running a ZooKeeper-based Apache Kafka cluster. entityOperator EntityOperatorSpec Configuration of the Entity Operator. clusterCa CertificateAuthority Configuration of the cluster certificate authority. clientsCa CertificateAuthority Configuration of the clients certificate authority. cruiseControl CruiseControlSpec Configuration for Cruise Control deployment. Deploys a Cruise Control instance when specified. jmxTrans JmxTransSpec The jmxTrans property has been deprecated. JMXTrans is deprecated and related resources removed in Streams for Apache Kafka 2.5. As of Streams for Apache Kafka 2.5, JMXTrans is not supported anymore and this option is ignored. kafkaExporter KafkaExporterSpec Configuration of the Kafka Exporter. Kafka Exporter can provide additional metrics, for example lag of consumer group at topic/partition. maintenanceTimeWindows string array A list of time windows for maintenance tasks (that is, certificates renewal). Each time window is defined by a cron expression.

Commands:
Chapter 4. Important links Red Hat AMQ 7 Supported Configurations Red Hat AMQ 7 Component Details AMQ Clients 2.7 Release Notes AMQ Clients 2.6 Release Notes AMQ Clients 2.5 Release Notes AMQ Clients 2.4 Release Notes AMQ Clients 2.3 Release Notes AMQ Clients 2.2 Release Notes AMQ Clients 2.1 Release Notes AMQ Clients 2.0 Release Notes AMQ Clients 1.2 Release Notes AMQ Clients 1.1 Release Notes Revised on 2020-10-08 11:29:42 UTC

Commands:
16.3. Using the Same Service Principal for Multiple Services Within a cluster, the same service principal can be used for multiple services, spread across different machines. Retrieve a service principal using the ipa-getkeytab command. Either direct multiple servers or services to use the same file, or copy the file to individual servers as required.

Commands:
ipa-getkeytab -s kdc.example.com -p HTTP/server.example.com -k /etc/httpd/conf/krb5.keytab -e aes256-cts
2.3. Monitoring System Capacity Monitoring system capacity is done as part of an ongoing capacity planning program. Capacity planning uses long-term resource monitoring to determine rates of change in the utilization of system resources. Once these rates of change are known, it becomes possible to conduct more accurate long-term planning regarding the procurement of additional resources. Monitoring done for capacity planning purposes is different from performance monitoring in two ways: The monitoring is done on a more-or-less continuous basis The monitoring is usually not as detailed The reason for these differences stems from the goals of a capacity planning program. Capacity planning requires a "big picture" viewpoint; short-term or anomalous resource usage is of little concern. Instead, data is collected over a period of time, making it possible to categorize resource utilization in terms of changes in workload. In more narrowly-defined environments, (where only one application is run, for example) it is possible to model the application's impact on system resources. This can be done with sufficient accuracy to make it possible to determine, for example, the impact of five more customer service representatives running the customer service application during the busiest time of the day.

Commands:
Chapter 1. Introduction to OpenShift Data Foundation Red Hat OpenShift Data Foundation is a highly integrated collection of cloud storage and data services for Red Hat OpenShift Container Platform. It is available as part of the Red Hat OpenShift Container Platform Service Catalog, packaged as an operator to facilitate simple deployment and management. Red Hat OpenShift Data Foundation services are primarily made available to applications by way of storage classes that represent the following components: Block storage devices, catering primarily to database workloads. Prime examples include Red Hat OpenShift Container Platform logging and monitoring, and PostgreSQL. Important Block storage should be used for any workload only when it does not require sharing the data across multiple containers. Shared and distributed file system, catering primarily to software development, messaging, and data aggregation workloads. Examples include Jenkins build sources and artifacts, Wordpress uploaded content, Red Hat OpenShift Container Platform registry, and messaging using JBoss AMQ. Multicloud object storage, featuring a lightweight S3 API endpoint that can abstract the storage and retrieval of data from multiple cloud object stores. On premises object storage, featuring a robust S3 API endpoint that scales to tens of petabytes and billions of objects, primarily targeting data intensive applications. Examples include the storage and access of row, columnar, and semi-structured data with applications like Spark, Presto, Red Hat AMQ Streams (Kafka), and even machine learning frameworks like TensorFlow and Pytorch. Note Running PostgresSQL workload on CephFS persistent volume is not supported and it is recommended to use RADOS Block Device (RBD) volume. For more information, see the knowledgebase solution ODF Database Workloads Must Not Use CephFS PVs/PVCs . Red Hat OpenShift Data Foundation version 4.x integrates a collection of software projects, including: Ceph, providing block storage, a shared and distributed file system, and on-premises object storage Ceph CSI, to manage provisioning and lifecycle of persistent volumes and claims NooBaa, providing a Multicloud Object Gateway OpenShift Data Foundation, Rook-Ceph, and NooBaa operators to initialize and manage OpenShift Data Foundation services.

Commands:
Chapter 5. Maintaining Referential Integrity Referential Integrity is a database mechanism that ensures relationships between related entries are maintained. In the Directory Server, the Referential Integrity can be used to ensure that an update to one entry in the directory is correctly reflected in any other entries that reference to the updated entry. For example, if a user's entry is removed from the directory and Referential Integrity is enabled, the server also removes the user from any groups of which the user is a member. If Referential Integrity is not enabled, the user remains a member of the group until manually removed by the administrator. This is an important feature if you are integrating the Directory Server with other products that rely on the directory for user and group management. 5.1. How Referential Integrity Works When the Referential Integrity Postoperation plug-in is enabled, it performs integrity updates on specified attributes immediately after a delete or rename operation. By default, the Referential Integrity Postoperation plug-in is disabled. Note You must enable Referential Integrity Postoperation plug-in on all suppliers in a multi-supplier replication environment. When you delete, rename, or move a user or group entry within the directory, the operation is logged to the Referential Integrity log file. For the distinguished names (DN) in the log file, Directory Server searches and updates in intervals the attributes set in the plug-in configuration: For entries, marked in the log file as deleted, the corresponding attribute in the directory is deleted. For entries, marked in the log file as renamed or moved, the value of the corresponding attribute in the directory is renamed. By default, when the Referential Integrity Postoperation plug-in is enabled, it performs integrity updates on the member , uniquemember , owner , and seeAlso attributes immediately after a delete or rename operation. However, you can configure the behavior of the Referential Integrity Postoperation plug-in to suit the needs of the directory in several different ways: Record Referential Integrity updates in the replication change log. Modify the update interval. Select the attributes to which to apply Referential Integrity. Disable Referential Integrity. All attributes used in referential integrity must be indexed for presence, equality, and substring; not indexing those attributes results poor server performance for modify and delete operations. See Section 13.2, "Creating Standard Indexes" for more information about checking and creating indexes.

Commands:
nsIndexType: pres nsIndexType: eq nsIndexType: sub
Chapter 10. Configuring kube-rbac-proxy for Serving The kube-rbac-proxy component provides internal authentication and authorization capabilities for Knative Serving. 10.1. Configuring kube-rbac-proxy resources for Serving 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 Serving kube-rbac-proxy minimum and maximum CPU and memory allocation: KnativeServing CR example apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving 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: KnativeServing metadata: name: knative-serving namespace: knative-serving 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
2.4.2. Vulnerable Client Applications Although an administrator may have a fully secure and patched server, that does not mean remote users are secure when accessing it. For instance, if the server offers Telnet or FTP services over a public network, an attacker can capture the plain text usernames and passwords as they pass over the network, and then use the account information to access the remote user's workstation. Even when using secure protocols, such as SSH, a remote user may be vulnerable to certain attacks if they do not keep their client applications updated. For instance, v.1 SSH clients are vulnerable to an X-forwarding attack from malicious SSH servers. Once connected to the server, the attacker can quietly capture any keystrokes and mouse clicks made by the client over the network. This problem was fixed in the v.2 SSH protocol, but it is up to the user to keep track of what applications have such vulnerabilities and update them as necessary. Chapter 4, Workstation Security discusses in more detail what steps administrators and home users should take to limit the vulnerability of computer workstations.

Commands:
Chapter 8. Windows node upgrades You can ensure your Windows nodes have the latest updates by upgrading the Windows Machine Config Operator (WMCO). 8.1. Windows Machine Config Operator upgrades When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is upgraded based on the upgrade channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM). The WMCO upgrade results in the Kubernetes components in the Windows machine being upgraded. Note If you are upgrading to a new version of the WMCO and want to use cluster monitoring, you must have the openshift.io/cluster-monitoring=true label present in the WMCO namespace. If you add the label to a pre-existing WMCO namespace, and there are already Windows nodes configured, restart the WMCO pod to allow monitoring graphs to display. For a non-disruptive upgrade, the WMCO terminates the Windows machines configured by the version of the WMCO and recreates them using the current version. This is done by deleting the Machine object, which results in the drain and deletion of the Windows node. To facilitate an upgrade, the WMCO adds a version annotation to all the configured nodes. During an upgrade, a mismatch in version annotation results in the deletion and recreation of a Windows machine. To have minimal service disruptions during an upgrade, the WMCO only updates one Windows machine at a time. Important The WMCO is only responsible for updating Kubernetes components, not for Windows operating system updates. You provide the Windows image when creating the VMs; therefore, you are responsible for providing an updated image. You can provide an updated Windows image by changing the image configuration in the MachineSet spec. For more information on Operator upgrades using the Operator Lifecycle Manager (OLM), see Updating installed Operators .

Commands:
2.3. Boot Loader Options Figure 2.3. Boot Loader Options GRUB is the default boot loader for Red Hat Enterprise Linux. If you do not want to install a boot loader, select Do not install a boot loader . If you choose not to install a boot loader, make sure you create a boot diskette or have another way to boot your system, such as a third-party boot loader. You must choose where to install the boot loader (the Master Boot Record or the first sector of the /boot partition). Install the boot loader on the MBR if you plan to use it as your boot loader. To pass any special parameters to the kernel to be used when the system boots, enter them in the Kernel parameters text field. For example, if you have an IDE CD-ROM Writer, you can tell the kernel to use the SCSI emulation driver that must be loaded before using cdrecord by configuring hdd=ide-scsi as a kernel parameter (where hdd is the CD-ROM device). You can password protect the GRUB boot loader by configuring a GRUB password. Select Use GRUB password , and enter a password in the Password field. Type the same password in the Confirm Password text field. To save the password as an encrypted password in the file, select Encrypt GRUB password . If the encryption option is selected, when the file is saved, the plain text password that you typed are encrypted and written to the kickstart file. If type an already encrypted password, unselect to encrypt it. If Upgrade an existing installation is selected on the Installation Method page, select Upgrade existing boot loader to upgrade the existing boot loader configuration, while preserving the old entries.

Commands:
5.2.25. /proc/pci This file contains a full listing of every PCI device on the system. Depending on the number of PCI devices, /proc/pci can be rather long. A sampling of this file from a basic system looks similar to the following: This output shows a list of all PCI devices, sorted in the order of bus, device, and function. Beyond providing the name and version of the device, this list also gives detailed IRQ information so an administrator can quickly look for conflicts. Note To get a more readable version of this information, type:

Commands:
Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe4000000 [0xe7ffffff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3). Master Capable. Latency=64. Min Gnt=128. Bus 0, device 4, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 4, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=32. I/O at 0xd800 [0xd80f]. Bus 0, device 4, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 5. Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 4, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). IRQ 9. Bus 0, device 9, function 0: Ethernet controller: Lite-On Communications Inc LNE100TX (rev 33). IRQ 5. Master Capable. Latency=32. I/O at 0xd000 [0xd0ff]. Non-prefetchable 32 bit memory at 0xe3000000 [0xe30000ff]. Bus 0, device 12, function 0: VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 1). IRQ 11. Master Capable. Latency=32. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xdc000000 [0xdfffffff].
/sbin/lspci -vb
7.71. hal-info 7.71.1. RHBA-2015:1268 - hal-info bug fix update An updated hal-info package that fixes one bug and adds one enhancement is now available for Red Hat Enterprise Linux 6. The hal-info package contains various device information files (also known as .fdi files) for the hal package. Bug Fix BZ# 841419 Previously, the "Mic Mute" and "Touchpad Toggle" keys did not transmit the correct symbol in Lenovo laptops. With this update, the aforementioned keys are correctly recognized by the X.Org Server, and the XF86AudioMicMute and XF86TouchpadToggle signals are transmitted successfully. Enhancement BZ# 1172669 To support the various "Fn" keys on latest Toshiba laptops, this update changes the hal-info remapping rules for Toshiba laptops from the provided kernel keycode to a keycode compatible with X. Users of hal-info are advised to upgrade to this updated package, which fixes this bug and adds this enhancement.

Commands: