mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Ceph administration A Red Hat Ceph Storage cluster is the foundation for all Ceph deployments. After deploying a Red Hat Ceph Storage cluster, there are administrative operations for keeping a Red Hat Ceph Storage cluster healthy and performing optimally. The Red Hat Ceph Storage Administration Guide helps storage administrators to perform such tasks as: How do I check the health of my Red Hat Ceph Storage cluster? How do I start and stop the Red Hat Ceph Storage cluster services? How do I add or remove an OSD from a running Red Hat Ceph Storage cluster? How do I manage user authentication and access controls to the objects stored in a Red Hat Ceph Storage cluster? I want to understand how to use overrides with a Red Hat Ceph Storage cluster. I want to monitor the performance of the Red Hat Ceph Storage cluster. A basic Ceph storage cluster consist of two types of daemons: A Ceph Object Storage Device (OSD) stores data as objects within placement groups assigned to the OSD A Ceph Monitor maintains a master copy of the cluster map A production system will have three or more Ceph Monitors for high availability and typically a minimum of 50 OSDs for acceptable load balancing, data re-balancing and data recovery. Additional Resources Red Hat Ceph Storage Installation Guide

Commands:
Chapter 1. Required Infrastructure Component Versions The following infrastructure components are required when using the Red Hat build of Node.js. Except for components that are explicitly designated as supported, Red Hat does not provide support for these components. Component name Version Nodeshift 2.1.1 npm 10 10.9.0 OpenShift Container Platform (OCP) [a] 3.11, 4.5 git 2.0 or later oc command line tool 3.11 or later [b] [a] OCP is supported by Red Hat [b] The version of the oc CLI tool should correspond to the version of OCP that you are using.

Commands:
Chapter 5. Quay.io organizations overview In = Quay.io an organization is a grouping of users, repositories, and teams. It provides a means to organize and manage access control and permissions within the registry. With organizations, administrators can assign roles and permissions to users and teams. Other useful information about organizations includes the following: You cannot have an organization embedded within another organization. To subdivide an organization, you use teams. Organizations cannot contain users directly. You must first add a team, and then add one or more users to each team. Note Individual users can be added to specific repositories inside of an organization. Consequently, those users are not members of any team on the Repository Settings page. The Collaborators View on the Teams and Memberships page shows users who have direct access to specific repositories within the organization without needing to be part of that organization specifically. Teams can be set up in organizations as just members who use the repositories and associated images, or as administrators with special privileges for managing the Organization. Users can create their own organization to share repositories of container images. This can be done through the Quay.io UI. 5.1. Creating an organization by using the UI Use the following procedure to create a new organization by using the UI. Procedure Log in to your Red Hat Quay registry. Click Organization in the navigation pane. Click Create Organization . Enter an Organization Name , for example, testorg . Enter an Organization Email . Click Create . Now, your example organization should populate under the Organizations page. 5.2. Organization settings With = Quay.io, some basic organization settings can be adjusted by using the UI. This includes adjusting general settings, such as the e-mail address associated with the organization, and time machine settings, which allows administrators to adjust when a tag is garbage collected after it is permanently deleted. Use the following procedure to alter your organization settings by using the v2 UI. Procedure On the v2 UI, click Organizations . Click the name of the organization that you will create the robot account for, for example, test-org . Click the Settings tab. Optional. Enter the email address associated with the organization. Optional. Set the allotted time for the Time Machine feature to one of the following: A few seconds A day 7 days 14 days A month Click Save .

Commands:
Preface As a Red Hat Hybrid Cloud user, you can use services for the public cloud, private clouds, and on-premises infrastructure. Use this guide to learn how to configure global settings for your Red Hat account and to learn more about cloud services available in the Hybrid Cloud Console. Prerequisites You are logged in to the Hybrid Cloud Console with your Red Hat account. You are using a supported web browser. For details about web browser requirements, see the Browser Support link at the bottom of the Hybrid Cloud Console landing page.

Commands:
7.283. xorg-x11-drv-qxl 7.283.1. RHBA-2013:0308 - xorg-x11-drv-qxl bug fix and enhancement update Updated xorg-x11-drv-qxl packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-qxl packages provide an X11 video driver for the QEMU QXL video accelerator. This driver makes it possible to use Red Hat Enterprise Linux 6 as a guest operating system under the KVM kernel module and the QEMU multi-platform emulator, using the SPICE protocol. Note The xorg-x11-drv-qxl packages have been upgraded to upstream version 0.1.0, which adds support for multiple monitors and continuous resolution. It aslo provides a number of bug fixes and enhancements over the version. (BZ# 835249 , BZ# 787160 ) Bug Fixes BZ# 883578 Due to overlapping memory areas, remote-viewer became unresponsive after a migration of a guest playing a video. This update adjusts the monitors_config pointer to fix this issue, and migration of a guest, which is displaying video, works as expected. BZ# 896005 This update disables "surfaces" by default due to a performance regression with the rendering support. All users of xorg-x11-drv-qxl are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
17.2.6. Common Mistakes to Avoid The following is a list of recommendations on how to avoid common mistakes users make when configuring a nameserver: Use semicolons and curly brackets correctly An omitted semicolon or unmatched curly bracket in the /etc/named.conf file can prevent the named service from starting. Use period correctly In zone files, a period at the end of a domain name denotes a fully qualified domain name. If omitted, the named service will append the name of the zone or the value of USDORIGIN to complete it. Increment the serial number when editing a zone file If the serial number is not incremented, the primary nameserver will have the correct, new information, but the secondary nameservers will never be notified of the change, and will not attempt to refresh their data of that zone. Configure the firewall If a firewall is blocking connections from the named service to other nameservers, the recommended practice is to change the firewall settings. Warning According to the recent research in DNS security, using a fixed UDP source port for DNS queries is a potential security vulnerability that could allow an attacker to conduct cache-poisoning attacks more easily. To prevent this, configure your firewall to allow queries from a random UDP source port.

Commands:
Chapter 161. KafkaNodePoolTemplate schema reference Used in: KafkaNodePoolSpec Property Property type Description podSet ResourceTemplate Template for Kafka StrimziPodSet resource. pod PodTemplate Template for Kafka Pods . perPodService ResourceTemplate Template for Kafka per-pod Services used for access from outside of OpenShift. perPodRoute ResourceTemplate Template for Kafka per-pod Routes used for access from outside of OpenShift. perPodIngress ResourceTemplate Template for Kafka per-pod Ingress used for access from outside of OpenShift. persistentVolumeClaim ResourceTemplate Template for all Kafka PersistentVolumeClaims . kafkaContainer ContainerTemplate Template for the Kafka broker container. initContainer ContainerTemplate Template for the Kafka init container.

Commands:
Chapter 2. Upgrading the Red Hat build of Keycloak server 2.1. Preparing for upgrading Procedure Back up the old installation, such as configuration, themes, and so on. Back up the database using instructions in the documentation for your relational database. The database will no longer be compatible with the old server after the upgrade. If you need to revert the upgrade, first restore the old installation, and then restore the database from the backup copy. Handle any open transactions and delete the data/tx-object-store/ transaction directory. Note In a minor upgrade of Red Hat build of Keycloak, all user sessions are lost. After the upgrade, all users will have to log in again. 2.2. Downloading the server ZIP file Procedure Download Red Hat build of Keycloak from the Red Hat website and extract it. Move the ZIP file to the desired location. Extract the archive. After extracting this file, you should have a directory that is named rhbk-22.0.13 . Copy conf/ , providers/ and themes/ from the installation to the new installation. 2.3. Database migration Red Hat build of Keycloak can automatically migrate the database schema, or you can choose to do it manually. By default, the database is automatically migrated when you start the new installation for the first time. 2.3.1. Automatic relational database migration To perform an automatic migration, start the server connected to the desired database. If the database schema has changed for the new version of the server, it will be migrated. Creating an index on huge tables with millions of records can be very time-consuming and possibly cause a major service disruption. Therefore, a threshold exists to limit the number of records allowed for the index. A warning message appears in the server logs with SQL commands you can apply later manually. To change the threshold, set the index-creation-threshold property, value for the default connections-liquibase provider: kc.[sh|bat] start --spi-connections-liquibase-default-index-creation-threshold=300000 2.3.2. Manual relational database migration To enable manual upgrading of the database schema, set the migration-strategy property value to "manual" for the default connections-jpa provider: kc.[sh|bat] start --spi-connections-jpa-legacy-migration-strategy=manual When you start the server with this configuration, the server checks if the database needs to be migrated. The required changes are written to the bin/keycloak-database-update.sql SQL file that you can review and manually run against the database. If you want to change the path and name of the exported SQL file, set the migration-export property for the default connections-jpa provider: kc.[sh|bat] start --spi-connections-jpa-legacy-migration-export=<path>/<file.sql> For more details on applying this file to the database, see the documentation for your relational database. After the changes have been written to the file, the server exits.

Commands:
kc.[sh|bat] start --spi-connections-liquibase-default-index-creation-threshold=300000
kc.[sh|bat] start --spi-connections-jpa-legacy-migration-strategy=manual
kc.[sh|bat] start --spi-connections-jpa-legacy-migration-export=<path>/<file.sql>
Chapter 1. OpenShift Container Platform storage overview OpenShift Container Platform supports multiple types of storage, both for on-premise and cloud providers. You can manage container storage for persistent and non-persistent data in an OpenShift Container Platform cluster. 1.1. Storage Types OpenShift Container Platform storage is broadly classified into two categories, namely ephemeral storage and persistent storage. 1.1.1. Ephemeral storage Pods and containers are ephemeral or transient in nature and designed for stateless applications. Ephemeral storage allows administrators and developers to better manage the local storage for some of their operations. For more information about ephemeral storage overview, types, and management, see Understanding ephemeral storage . 1.1.2. Persistent storage Stateful applications deployed in containers require persistent storage. OpenShift Container Platform uses a pre-provisioned storage framework called persistent volumes (PV) to allow cluster administrators to provision persistent storage. The data inside these volumes can exist beyond the lifecycle of an individual pod. Developers can use persistent volume claims (PVCs) to request storage requirements. For more information about persistent storage overview, configuration, and lifecycle, see Understanding persistent storage . 1.2. Container Storage Interface (CSI) CSI is an API specification for the management of container storage across different container orchestration (CO) systems. You can manage the storage volumes within the container native environments, without having specific knowledge of the underlying storage infrastructure. With the CSI, storage works uniformly across different container orchestration systems, regardless of the storage vendors you are using. For more information about CSI, see Using Container Storage Interface (CSI) . 1.3. Dynamic Provisioning Dynamic Provisioning allows you to create storage volumes on-demand, eliminating the need for cluster administrators to pre-provision storage. For more information about dynamic provisioning, see Dynamic provisioning .

Commands:
Chapter 6. Enabling Custom Home Directories Using authconfig If LDAP users have home directories that are not in /home and the system is configured to create home directories the first time users log in, then these directories are created with the wrong permissions. Apply the correct SELinux context and permissions from the /home directory to the home directory that is created on the local system. For example: Install the oddjob-mkhomedir package on the system. This package provides the pam_oddjob_mkhomedir.so library, which the authconfig command uses to create home directories. The pam_oddjob_mkhomedir.so library, unlike the default pam_mkhomedir.so library, can create SELinux labels. The authconfig command automatically uses the pam_oddjob_mkhomedir.so library if it is available. Otherwise, it will default to using pam_mkhomedir.so . Make sure the oddjobd service is running. Run the authconfig command and enable home directories. In the command line, this is done through the --enablemkhomedir option. In the UI, there is an option in the Advanced Options tab ( Create home directories on the first login ) to create a home directory automatically the first time that a user logs in. Figure 6.1. Home Directory Option This option is beneficial with accounts that are managed centrally, such as with LDAP. However, this option should not be selected if a system like automount is used to manage user home directories. If home directories were created before the home directory configuration was changed, then correct the permissions and SELinux contexts. For example:

Commands:
semanage fcontext -a -e /home /home/locale
authconfig --enablemkhomedir --update
semanage fcontext -a -e /home /home/locale restorecon -R -v /home/locale
8.261. xfsdump 8.261.1. RHBA-2014:1565 - xfsdump bug fix update Updated xfsdump packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The xfsdump packages provide several utilities for managing XFS file systems, including xfsrestore and xfsdump. Users of xfsdump are advised to upgrade to these updated packages, which fix these bugs.

Commands:
18.12.11. Advanced Filter Configuration Topics The following sections discuss advanced filter configuration topics. 18.12.11.1. Connection tracking The network filtering subsystem (on Linux) makes use of the connection tracking support of IP tables. This helps in enforcing the directionality of network traffic (state match) as well as counting and limiting the number of simultaneous connections towards a guest virtual machine. As an example, if a guest virtual machine has TCP port 8080 open as a server, clients may connect to the guest virtual machine on port 8080. Connection tracking and enforcement of directionality then prevents the guest virtual machine from initiating a connection from (TCP client) port 8080 to the host physical machine back to a remote host physical machine. More importantly, tracking helps to prevent remote attackers from establishing a connection back to a guest virtual machine. For example, if the user inside the guest virtual machine established a connection to port 80 on an attacker site, then the attacker will not be able to initiate a connection from TCP port 80 back towards the guest virtual machine. By default the connection state match that enables connection tracking and then enforcement of directionality of traffic is turned on. Example 18.9. XML example for turning off connections to the TCP port The following shows an example XML fragment where this feature has been turned off for incoming connections to TCP port 12345. This now allows incoming traffic to TCP port 12345, but would also enable the initiation from (client) TCP port 12345 within the VM, which may or may not be desirable.

Commands:
[...] <rule direction='in' action='accept' statematch='false'> <cp dstportstart='12345'/> </rule> [...]
Chapter 47. ZookeeperClusterTemplate schema reference Used in: ZookeeperClusterSpec Property Property type Description statefulset StatefulSetTemplate The statefulset property has been deprecated. Support for StatefulSets was removed in Streams for Apache Kafka 2.5. This property is ignored. Template for ZooKeeper StatefulSet . pod PodTemplate Template for ZooKeeper Pods . clientService InternalServiceTemplate Template for ZooKeeper client Service . nodesService InternalServiceTemplate Template for ZooKeeper nodes Service . persistentVolumeClaim ResourceTemplate Template for all ZooKeeper PersistentVolumeClaims . podDisruptionBudget PodDisruptionBudgetTemplate Template for ZooKeeper PodDisruptionBudget . zookeeperContainer ContainerTemplate Template for the ZooKeeper container. serviceAccount ResourceTemplate Template for the ZooKeeper service account. jmxSecret ResourceTemplate Template for Secret of the Zookeeper Cluster JMX authentication. podSet ResourceTemplate Template for ZooKeeper StrimziPodSet resource.

Commands:
23.7. Memory Tuning <domain> ... <memtune> <hard_limit unit='G'>1</hard_limit> <soft_limit unit='M'>128</soft_limit> <swap_hard_limit unit='G'>2</swap_hard_limit> <min_guarantee unit='bytes'>67108864</min_guarantee> </memtune> ... </domain> Figure 23.9. Memory tuning Although <memtune> is optional, the components of this section of the domain XML are as follows: Table 23.5. Memory tuning elements Element Description <memtune> Provides details regarding the memory tunable parameters for the domain. If this is omitted, it defaults to the operating system provided defaults. As parameters are applied to the process as a whole, when setting limits, determine values by adding the guest virtual machine RAM to the guest virtual machine video RAM, allowing for some memory overhead. For each tunable, it is possible to designate which unit the number is in on input, using the same values as for <memory> . For backwards compatibility, output is always in kibibytes (KiB). <hard_limit> The maximum memory the guest virtual machine can use. This value is expressed in kibibytes (blocks of 1024 bytes). <soft_limit> The memory limit to enforce during memory contention. This value is expressed in kibibytes (blocks of 1024 bytes). <swap_hard_limit> The maximum memory plus swap the guest virtual machine can use. This value is expressed in kibibytes (blocks of 1024 bytes). This must be more than <hard_limit> value. <min_guarantee> The guaranteed minimum memory allocation for the guest virtual machine. This value is expressed in kibibytes (blocks of 1024 bytes).

Commands:
<domain> <memtune> <hard_limit unit='G'>1</hard_limit> <soft_limit unit='M'>128</soft_limit> <swap_hard_limit unit='G'>2</swap_hard_limit> <min_guarantee unit='bytes'>67108864</min_guarantee> </memtune> </domain>
11.6. Consistent Network Device Naming Using biosdevname This feature, implemented through the biosdevname udev helper utility, will change the name of all embedded network interfaces, PCI card network interfaces, and virtual function network interfaces from the existing eth[0123...] to the new naming convention as shown in Table 11.2, "The biosdevname Naming Convention" . Note that unless the system is a Dell system, or biosdevname is explicitly enabled as described in Section 11.6.2, "Enabling and Disabling the Feature" , the systemd naming scheme will take precedence. Table 11.2. The biosdevname Naming Convention Device Old Name New Name Embedded network interface (LOM) eth[0123...] em[1234...] [a] PCI card network interface eth[0123...] p< slot >p< ethernet port > [b] Virtual function eth[0123...] p< slot >p< ethernet port >_< virtual interface > [c] [a] New enumeration starts at 1 . [b] For example: p3p4 [c] For example: p3p4_1 11.6.1. System Requirements The biosdevname program uses information from the system's BIOS, specifically the type 9 (System Slot) and type 41 (Onboard Devices Extended Information) fields contained within the SMBIOS. If the system's BIOS does not have SMBIOS version 2.6 or higher and this data, the new naming convention will not be used. Most older hardware does not support this feature because of a lack of BIOSes with the correct SMBIOS version and field information. For BIOS or SMBIOS version information, contact your hardware vendor. For this feature to take effect, the biosdevname package must also be installed. To install it, issue the following command as root : 11.6.2. Enabling and Disabling the Feature To disable this feature, pass the following option on the boot command line, both during and after installation: To enable this feature, pass the following option on the boot command line, both during and after installation: Unless the system meets the minimum requirements, this option will be ignored and the system will use the systemd naming scheme as described in the beginning of the chapter. If the biosdevname install option is specified, it must remain as a boot option for the lifetime of the system.

Commands:
~]# yum install biosdevname
biosdevname=0
biosdevname=1
Chapter 64. Condition schema reference Used in: KafkaBridgeStatus , KafkaConnectorStatus , KafkaConnectStatus , KafkaMirrorMaker2Status , KafkaMirrorMakerStatus , KafkaNodePoolStatus , KafkaRebalanceStatus , KafkaStatus , KafkaTopicStatus , KafkaUserStatus , StrimziPodSetStatus Property Description type The unique identifier of a condition, used to distinguish between other conditions in the resource. string status The status of the condition, either True, False or Unknown. string lastTransitionTime Last time the condition of a type changed from one status to another. The required format is 'yyyy-MM-ddTHH:mm:ssZ', in the UTC time zone. string reason The reason for the condition's last transition (a single word in CamelCase). string message Human-readable message indicating details about the condition's last transition. string

Commands:
probe::socket.aio_read.return Name probe::socket.aio_read.return - Conclusion of message received via sock_aio_read Synopsis socket.aio_read.return Values family Protocol family value protocol Protocol value name Name of this probe state Socket state value success Was receive successful? (1 = yes, 0 = no) flags Socket flags value type Socket type value size Size of message received (in bytes) or error code if success = 0 Context The message receiver. Description Fires at the conclusion of receiving a message on a socket via the sock_aio_read function

Commands: