mtpti5iD/redhat-docs_dataset huggingface dataset:
4.114. kdeadmin 4.114.1. RHBA-2011:1117 - kdeadmin bug fix update An updated kdeadmin package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The kdeadmin package contains administrative tools for the K Desktop Environment. Bug Fixes BZ# 587904 Prior to this update, the icon for the ksystemlog program did not appear correctly in GNOME Application's System Tools menu. This bug has been fixed in this update so that the icon is now displayed as expected. BZ# 692737 Prior to this update, the Network Settings component that was included in KDE's System Settings was not compatible with NetworkManager in Red Hat Enterprise Linux 6. As a result, the spurious message "Your Platform is Not Supported" was displayed in the aforementioned component's dialog window. Furthermore, no network interface controllers (NICs) were displayed in the dialog window. These problems have been resolved in this update by removing the Network Settings component from KDE's System Settings. Users of kdeadmin are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 97. KafkaTopicSpec schema reference Used in: KafkaTopic Property Description partitions The number of partitions the topic should have. This cannot be decreased after topic creation. It can be increased after topic creation, but it is important to understand the consequences that has, especially for topics with semantic partitioning. When absent this will default to the broker configuration for num.partitions . integer replicas The number of replicas the topic should have. When absent this will default to the broker configuration for default.replication.factor . integer config The topic configuration. map topicName The name of the topic. When absent this will default to the metadata.name of the topic. It is recommended to not set this unless the topic name is not a valid OpenShift resource name. string

Commands:
Chapter 5. Ceph metrics for Datadog The Datadog agent collects the following metrics from Ceph. These metrics may be included in custom dashboards and in alerts. Metric Name Description ceph.commit_latency_ms The time taken to commit an operation to the journal. ceph.apply_latency_ms Time taken to flush an update to disks. ceph.op_per_sec The number of I/O operations per second for given pool. ceph.read_bytes_sec The bytes per second being read. ceph.write_bytes_sec The bytes per second being written. ceph.num_osds The number of known storage daemons. ceph.num_in_osds The number of participating storage daemons. ceph.num_up_osds The number of online storage daemons. ceph.num_pgs The number of placement groups available. ceph.num_mons The number of monitor daemons. ceph.aggregate_pct_used The overall capacity usage metric. ceph.total_objects The object count from the underlying object store. ceph.num_objects The object count for a given pool. ceph.read_bytes The per-pool read bytes. ceph.write_bytes The per-pool write bytes. ceph.num_pools The number of pools. ceph.pgstate.active_clean The number of active+clean placement groups. ceph.read_op_per_sec The per-pool read operations per second. ceph.write_op_per_sec The per-pool write operations per second. ceph.num_near_full_osds The number of nearly full OSDs. ceph.num_full_osds The number of full OSDs. ceph.osd.pct_used The percentage used of full or near-full OSDs.

Commands:
D.2. Setting Up Encrypted Communication between the Manager and an LDAP Server To set up encrypted communication between the Red Hat Virtualization Manager and an LDAP server, obtain the root CA certificate of the LDAP server, copy the root CA certificate to the Manager, and create a PEM-encoded CA certificate. The keystore type can be any Java-supported type. The following procedure uses the Java KeyStore (JKS) format. Note For more information on creating a PEM-encoded CA certificate and importing certificates, see the X.509 CERTIFICATE TRUST STORE section of the README file at /usr/share/doc/ovirt-engine-extension-aaa-ldap- version . Creating a PEM-encoded CA certificate On the Red Hat Virtualization Manager, copy the root CA certificate of the LDAP server to the /tmp directory and import the root CA certificate using keytool to create a PEM-encoded CA certificate. The following command imports the root CA certificate at /tmp/myrootca.pem and creates a PEM-encoded CA certificate myrootca.jks under /etc/ovirt-engine/aaa/ . Note down the certificate's location and password. If you are using the interactive setup tool, this is all the information you need. If you are configuring the LDAP server manually, follow the rest of the procedure to update the configuration files. Update the /etc/ovirt-engine/aaa/profile1.properties file with the certificate information: Note USD{local:_basedir} is the directory where the LDAP property configuration file resides and points to the /etc/ovirt-engine/aaa directory. If you created the PEM-encoded CA certificate in a different directory, replace USD{local:_basedir} with the full path to the certificate. To use startTLS (recommended): To use SSL: To continue configuring an external LDAP provider, see Configuring an External LDAP Provider . To continue configuring LDAP and Kerberos for Single Sign-on, see Configuring LDAP and Kerberos for Single Sign-on .

Commands:
keytool -importcert -noprompt -trustcacerts -alias myrootca -file /tmp/myrootca.pem -keystore /etc/ovirt-engine/aaa/myrootca.jks -storepass password
Create keystore, import certificate chain and uncomment pool.default.ssl.startTLS = true pool.default.ssl.truststore.file = USD{local:_basedir}/ myrootca.jks pool.default.ssl.truststore.password = password
Create keystore, import certificate chain and uncomment pool.default.serverset.single.port = 636 pool.default.ssl.enable = true pool.default.ssl.truststore.file = USD{local:_basedir}/ myrootca.jks pool.default.ssl.truststore.password = password
2.8.2.6. Activating the IPTables Service The firewall rules are only active if the iptables service is running. To manually start the service, use the following command as the root user: To ensure that iptables starts when the system is booted, use the following command:

Commands:
~]# service iptables restart iptables: Applying firewall rules: [ OK ]
~]# chkconfig --level 345 iptables on
Chapter 1. Introduction to Red Hat Enterprise Linux for SAP Solutions Red Hat Enterprise Linux for SAP Solutions is a SAP specific offering, tailored to the needs of SAP workloads such as SAP NetWeaver, SAP S/4HANA and SAP HANA platform. 1.1. Red Hat Enterprise Linux for SAP Solutions Built on the foundation of Red Hat Enterprise Linux (RHEL) for SAP Applications with its packages and components, in addition to this foundation, the RHEL for SAP Solutions subscription includes the following: SAP-specific technical components to support SAP S/4HANA, SAP HANA, and SAP Business Applications. SAP-specific High Availability solutions for SAP S/4HANA, SAP HANA, and SAP Business Applications. RHEL System Roles for SAP for automation of operating system configuration to run SAP workloads. SAP tailored Red Hat Insights Dashboard and Smart Management helps streamline operations and to reduce costs Update Services for SAP Solutions or Extended Update Support (EUS), providing support for specific minor RHEL releases for up to four years from General Availability. See the RHEL Life Cycle web page for more information about EUS and Update Services for SAP Solutions. Note Update Services for SAP Solutions is only provided with RHEL for SAP Solutions. It is not available on any other RHEL products. Update Services for SAP Solutions is only provided on specified minor RHEL releases, which may be different from the EUS releases. The RHEL for SAP Solutions subscription may be used with Red Hat Enterprise Linux 6, but it does not include Update Services for SAP Solutions. However, EUS is available on specific RHEL 6 releases, and it can be used under the RHEL for SAP Solutions subscription to allow for easier migration.

Commands:
Chapter 10. Supported Configurations Supported configurations for the Streams for Apache Kafka 2.9 release. 10.1. Supported platforms The following platforms are tested for Streams for Apache Kafka 2.9 running with Kafka on the version of Red Hat Enterprise Linux (RHEL) stated. Operating System Architecture JVM RHEL 8 and 9 x86, amd64, ppc64le (IBM Power), s390x (IBM Z and IBM(R) LinuxONE), aarch64 (64-bit ARM) Java 11 (deprecated) and Java 17 Platforms are tested with Open JDK 11 and 17, though Java 11 is deprecated in Streams for Apache Kafka 2.7 and will be removed in version 3.0. The IBM JDK is supported but not regularly tested against during each release. Oracle JDK 11 is not supported. FIPS compliance Streams for Apache Kafka is designed for FIPS. To check which versions of RHEL are approved by the National Institute of Standards and Technology (NIST), see the Cryptographic Module Validation Program on the NIST website. 10.2. Supported clients Only client libraries built by Red Hat are supported for Streams for Apache Kafka. Currently, Streams for Apache Kafka only provides a Java client library, which is tested and supported on kafka-clients-3.8.0.redhat-00007 and newer. Clients are tested with Open JDK 11 and 17. 10.3. Supported Apache Kafka ecosystem In Streams for Apache Kafka, only the following components released directly from the Apache Software Foundation are supported: Apache Kafka Broker Apache Kafka Connect Apache MirrorMaker Apache MirrorMaker 2 Apache Kafka Java Producer, Consumer, Management clients, and Kafka Streams Apache ZooKeeper Note Apache ZooKeeper is supported solely as an implementation detail of Apache Kafka and should not be modified for other purposes. 10.4. Additional supported features Kafka Bridge Cruise Control Distributed Tracing See also, Chapter 12, Supported integration with Red Hat products . 10.5. Subscription limits and core usage Cores used by Red Hat components and product operators do not count against subscription limits. Additionally, cores or vCPUs allocated to ZooKeeper nodes are excluded from subscription compliance calculations and do not count towards a subscription. 10.6. Storage requirements Streams for Apache Kafka has been tested with block storage and is compatible with the XFS and ext4 file systems, both of which are commonly used with Kafka. File storage options, such as NFS, are not compatible. Additional resources For information on the supported configurations for the latest LTS release, see the Streams for Apache Kafka LTS Support Policy .

Commands:
Chapter 9. Upgrading Troubleshoot issues when upgrading to Ansible Automation Platform 2.5. 9.1. Issue - When upgrading from Ansible Automation Platform 2.4 to 2.5, connections to the automation controller API fail if the automation controller is behind a load balancer When upgrading Ansible Automation Platform 2.4 to 2.5, the upgrade is completed; however, connections to the platform gateway URL fail on the platform gateway UI if you are using the automation controller behind a load balancer. The following error message is displayed: Error connecting to Controller API To resolve this issue, perform the following tasks for all controller hosts: For each controller host, add the platform gateway URL as a trusted source in the CSRF_TRUSTED_ORIGIN setting in the settings.py file. For example, if you configured the platform gateway URL as https://www.example.com , you must add that URL in the settings.py file too as shown below: CSRF_TRUSTED_ORIGINS = ['https://appX.example.com:8443','https://www.example.com'] Restart each controller host by using the automation-controller-service restart command so that the URL changes are implemented. For the procedure, see Start, stop, and restart automation controller in Configuring automation execution .

Commands:
CSRF_TRUSTED_ORIGINS = ['https://appX.example.com:8443','https://www.example.com']
5.3.2. /proc/bus/ This directory contains information specific to the various buses available on the system. For example, on a standard system containing PCI and USB buses, current data on each of these buses is available within a subdirectory within /proc/bus/ by the same name, such as /proc/bus/pci/ . The subdirectories and files available within /proc/bus/ vary depending on the devices connected to the system. However, each bus type has at least one directory. Within these bus directories are normally at least one subdirectory with a numerical name, such as 001 , which contain binary files. For example, the /proc/bus/usb/ subdirectory contains files that track the various devices on any USB buses, as well as the drivers required for them. The following is a sample listing of a /proc/bus/usb/ directory: The /proc/bus/usb/001/ directory contains all devices on the first USB bus and the devices file identifies the USB root hub on the motherboard. The following is a example of a /proc/bus/usb/devices file:

Commands:
total 0 dr-xr-xr-x 1 root root 0 May 3 16:25 001 -r--r--r-- 1 root root 0 May 3 16:25 devices -r--r--r-- 1 root root 0 May 3 16:25 drivers
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
Chapter 26. Identity Management Identity Management ( IdM ) provides a unifying environment for standards-defined, common network services, including PAM, LDAP, Kerberos, DNS, NTP, and certificate services. IdM allows Red Hat Enterprise Linux systems to serve as domain controllers. [25] In Red Hat Enterprise Linux, the ipa-server package provides the IdM server. Enter the following command to see if the ipa-server package is installed: If it is not installed, enter the following command as the root user to install it: 26.1. Identity Management and SELinux Identity Management can map IdM users to configured SELinux roles per host so that it is possible to specify SELinux context for IdM access rights. During the user login process, the System Security Services Daemon ( SSSD ) queries the access rights defined for a particular IdM user. Then the pam_selinux module sends a request to the kernel to launch the user process with the proper SELinux context according to the IdM access rights, for example guest_u:guest_r:guest_t:s0 . For more information about Identity Management and SELinux, see the Linux Domain, Identity, Authentication, and Policy Guide for Red Hat Enterprise Linux 7. 26.1.1. Trust to Active Directory Domains In versions of Red Hat Enterprise Linux, Identity Management used the WinSync utility to allow users from Active Directory ( AD ) domains to access data stored on IdM domains. To do that, WinSync had to replicate the user and group data from the AD server to the local server and kept the data synchronized. In Red Hat Enterprise Linux 7, the SSSD daemon has been enhanced to work with AD and users are able to create a trusted relationship between IdM and AD domains. The user and group data are read directly from the AD server. Additionally, Kerberos cross-realm trust allowing single sign-on ( SSO ) authentication between the AD and IdM domains is provided. If SSO is set, users from the AD domains can access data protected by Kerberos that is stored on the IdM domains without requiring a password. This feature is not installed by default. To use it, install the additional ipa-server-trust-ad package. [25] For more information about Identity Management, see the Linux Domain, Identity, Authentication, and Policy Guide for Red Hat Enterprise Linux 7.

Commands:
~]USD rpm -q ipa-server package ipa-server is not installed
~]# yum install ipa-server
Chapter 13. Volume cloning A clone is a duplicate of an existing storage volume that is used as any standard volume. You create a clone of a volume to make a point in time copy of the data. A persistent volume claim (PVC) cannot be cloned with a different size. You can create up to 512 clones per PVC for both CephFS and RADOS Block Device (RBD). 13.1. Creating a clone Prerequisites Source PVC must be in Bound state and must not be in use. Note Do not create a clone of a PVC if a Pod is using it. Doing so might cause data corruption because the PVC is not quiesced (paused). Procedure Click Storage Persistent Volume Claims from the OpenShift Web Console. To create a clone, do one of the following: Beside the desired PVC, click Action menu (...) Clone PVC . Click on the PVC that you want to clone and click Actions Clone PVC . Enter a Name for the clone. Select the access mode of your choice. Important The ReadOnlyMany (ROX) access mode is a Developer Preview feature and is subject to Developer Preview support limitations. Developer Preview releases are not intended to be run in production environments and are not supported through the Red Hat Customer Portal case management system. If you need assistance with ReadOnlyMany feature, reach out to the ocs-devpreview@redhat.com mailing list and a member of the Red Hat Development Team will assist you as quickly as possible based on availability and work schedules. See Creating a clone or restoring a snapshot with the new readonly access mode to use the ROX access mode. Click Clone . You are redirected to the new PVC details page. Wait for the cloned PVC status to become Bound . The cloned PVC is now available to be consumed by the pods. This cloned PVC is independent of its dataSource PVC.

Commands:
B.8. Log tracepoints The tracepoints in this subsystem track blocks being added to and removed from the journal ( gfs2_pin ), as well as the time taken to commit the transactions to the log ( gfs2_log_flush ). This can be very useful when trying to debug journaling performance issues. The gfs2_log_blocks tracepoint keeps track of the reserved blocks in the log, which can help show if the log is too small for the workload, for example. The gfs2_ail_flush tracepoint is similar to the gfs2_log_flush tracepoint in that it keeps track of the start and end of flushes of the AIL list. The AIL list contains buffers which have been through the log, but have not yet been written back in place and this is periodically flushed in order to release more log space for use by the file system, or when a process requests a sync or fsync .

Commands:
Chapter 1. Ansible plug-ins for Red Hat Developer Hub 1.1. Red Hat Developer Hub Red Hat Developer Hub (RHDH) serves as an open developer platform designed for building developer portals. 1.2. Ansible plug-ins for Red Hat Developer Hub Ansible plug-ins for Red Hat Developer Hub deliver an Ansible-first Red Hat Developer Hub user experience that simplifies the automation experience for Ansible users of all skill levels. The Ansible plug-ins provide curated content and features to accelerate Ansible learner onboarding and streamline Ansible use case adoption across your organization. The Ansible plug-ins provide: A customized home page and navigation tailored to Ansible users. Curated Ansible learning paths to help users new to Ansible. Software templates for creating Ansible playbook and collection projects that follow best practices. Links to supported development environments and tools with opinionated configurations. 1.3. Architecture

Commands:
Chapter 5. Automation mesh nodes Automation mesh is an overlay network intended to ease the distribution of work across a large and dispersed collection of workers. This is done through nodes that establish peer-to-peer connections with each other by using existing networks. 5.1. Tested system configurations Each automation mesh VM has been tested with the following component requirements: 16 GB RAM, 4 CPUs, 60 GB local disk, and 3000 IOPS. 5.2. Network ports Automation mesh uses several ports to communicate with its services. These ports must be open and available for incoming connections to the Red Hat Ansible Automation Platform server for it to work. Ensure that these ports are available and are not blocked by the server firewall. Table 5.1. Network ports and protocols Port number Protocol Service Source Destination 80/443 HTTP/HTTPS Receptor Execution node OpenShift Container Platform mesh ingress 80/443 HTTP/HTTPS Receptor Hop node OpenShift Container Platform mesh ingress 27199 TCP Receptor OpenShift Container Platform cluster Execution node 27199 TCP Receptor OpenShift Container Platform cluster Hop node

Commands:
8.238. tboot 8.238.1. RHBA-2014:1495 - tboot bug fix and enhancement update Updated tboot packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The tboot packages provide the Trusted Boot (tboot) open source pre-kernel/VMM module. This module uses Intel Trusted Execution Technology (Intel TXT) to initialize the launch of operating system kernels and virtual machines. Note The tboot packages have been upgraded to upstream version 1.8.1, which provides a number of bug fixes and enhancements over the version. (BZ# 1037469 , BZ# 1065320 ) Users of tboot are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
4.2.3. Policy Selection Selecting the correct scheduler policy for an application's threads is not always a straightforward task. In general, realtime policies should be used for time critical or important tasks that need to be scheduled quickly and do not run for extended periods of time. Normal policies will generally yield better data throughput results than realtime policies because they let the scheduler run threads more efficiently (that is, they do not need to reschedule for pre-emption as often). If you are managing large numbers of threads and are concerned mainly with data throughput (network packets per second, writes to disk, etc.) then use SCHED_OTHER and let the system manage CPU utilization for you. If you are concerned with event response time (latency) then use SCHED_FIFO . If you have a small number of threads, consider isolating a CPU socket and moving your threads onto that socket's cores so that there are no other threads competing for time on the cores.

Commands: