mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Revision History 0.0-7 Tue Nov 12 2024, Kyle Walker ( kwalker@redhat.com ) Release of the Red Hat Enterprise Linux 9.5 Package manifest. 0.0-6 Tue Apr 30 2024, Kyle Walker ( kwalker@redhat.com ) Release of the Red Hat Enterprise Linux 9.4 Package manifest. 0.0-5 Wed Nov 8 2023, Kyle Walker ( kwalker@redhat.com ) Release of the Red Hat Enterprise Linux 9.3 Package manifest. 0.0-4 Wed May 10 2022, Kyle Walker ( kwalker@redhat.com ) Release of the Red Hat Enterprise Linux 9.2 Package manifest. 0.0-3 Wed Nov 16 2022, Kyle Walker ( kwalker@redhat.com ) Release of the Red Hat Enterprise Linux 9.1 Package manifest. Promote libvirt to Application Compatibility Level 2 0.0-2 Thu Jun 23 2022, Kyle Walker ( kwalker@redhat.com ) Promote libguestfs, libnbd, and nbdkit to Application Compatibility Level 2 Mark httpd, mariadb, perl, php, postgresql, python, and ruby as Application Compatibility Level 3. This is to denote these as Full Life Application Streams RHEL 9 Full Life Application Streams Release Life Cycle for more details. Mark openldap related components as Compatibility Level 4. Due to instability in the upstream component, it is necessary to reduce the compatibility level. 0.0-1 Fri May 13 2022, Kyle Walker ( kwalker@redhat.com ) Release of the Red Hat Enterprise Linux 9.0 Package manifest.

Commands:
16.4. Configuration Examples 16.4.1. Enabling SELinux Labeled NFS Support The following example demonstrates how to enable SELinux labeled NFS support. This example assumes that the nfs-utils package is installed, that the SELinux targeted policy is used, and that SELinux is running in enforcing mode. Note Steps 1-3 are supposed to be performed on the NFS server, nfs-srv . If the NFS server is running, stop it: Confirm that the server is stopped: Edit the /etc/sysconfig/nfs file to set the RPCNFSDARGS flag to "-V 4.2" : Start the server again and confirm that it is running. The output will contain information below, only the time stamp will differ: On the client side, mount the NFS server: All SELinux labels are now successfully passed from the server to the client: Note If you enable labeled NFS support for home directories or other content, the content will be labeled the same as it was on an EXT file system. Also note that mounting systems with different versions of NFS or an attempt to mount a server that does not support labeled NFS could cause errors to be returned.

Commands:
systemctl stop nfs
systemctl status nfs nfs-server.service - NFS Server Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; disabled) Active: inactive (dead)
Optional arguments passed to rpc.nfsd. See rpc.nfsd(8) RPCNFSDARGS="-V 4.2"
systemctl start nfs
systemctl status nfs nfs-server.service - NFS Server Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; disabled) Active: active (exited) since Wed 2013-08-28 14:07:11 CEST; 4s ago
mount -o v4.2 server:mntpoint localmountpoint
[nfs-srv]USD ls -Z file -rw-rw-r--. user user unconfined_u:object_r:svirt_image_t:s0 file [nfs-client]USD ls -Z file -rw-rw-r--. user user unconfined_u:object_r:svirt_image_t:s0 file
Appendix B. Provisioning FIPS-compliant hosts Satellite supports provisioning hosts that comply with the National Institute of Standards and Technology's Security Requirements for Cryptographic Modules standard, reference number FIPS 140-2, referred to here as FIPS. To enable the provisioning of hosts that are FIPS-compliant, complete the following tasks: Change the provisioning password hashing algorithm for the operating system Create a host group and set a host group parameter to enable FIPS For more information, see Creating a Host Group in Managing hosts . The provisioned hosts have the FIPS-compliant settings applied. To confirm that these settings are enabled, complete the steps in Section B.3, "Verifying FIPS mode is enabled" . B.1. Changing the provisioning password hashing algorithm To provision FIPS-compliant hosts, you must first set the password hashing algorithm that you use in provisioning to SHA256. This configuration setting must be applied for each operating system you want to deploy as FIPS-compliant. Procedure Identify the Operating System IDs: Update each operating system's password hash value. Note that you cannot use a comma-separated list of values. B.2. Setting the FIPS-enabled parameter To provision a FIPS-compliant host, you must create a host group and set the host group parameter fips_enabled to true . If this is not set to true , or is absent, the FIPS-specific changes do not apply to the system. You can set this parameter when you provision a host or for a host group. To set this parameter when provisioning a host, append --parameters fips_enabled=true to the Hammer command. For more information, see the output of the command hammer hostgroup set-parameter --help . B.3. Verifying FIPS mode is enabled To verify these FIPS compliance changes have been successful, you must provision a host and check its configuration. Procedure Log in to the host as root or with an admin-level account. Enter the following command: A value of 1 confirms that FIPS mode is enabled.

Commands:
hammer os list
hammer os update --password-hash SHA256 --title " My_Operating_System "
hammer hostgroup set-parameter --hostgroup " My_Host_Group " --name fips_enabled --value "true"
cat /proc/sys/crypto/fips_enabled
18.3. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: cvs_read_shadow This Boolean allows the cvs daemon to access the /etc/shadow file for user authentication. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, enter the following command: Enter the following command to view description of a particular Boolean: Note that the additional policycoreutils-devel package providing the sepolicy utility is required for this command to work.

Commands:
~]USD getsebool -a | grep service_name
~]USD sepolicy booleans -b boolean_name
Preface Thank you for your interest in Red Hat Ansible Automation Platform. Ansible Automation Platform is a commercial offering that helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments. This guide helps you to understand the requirements and processes behind setting up an automation mesh on a VM-based installation of Red Hat Ansible Automation Platform. This document has been updated to include information for the latest release of Ansible Automation Platform.

Commands:
6.15. Propagating the Configuration File to the Cluster Nodes After you have created or edited a cluster configuration file on one of the nodes in the cluster, you need to propagate that same file to all of the cluster nodes and activate the configuration. Use the following command to propagate and activate a cluster configuration file. When you use the --activate option, you must also specify the --sync option for the activation to take affect. To verify that all of the nodes specified in the hosts cluster configuration file have the identical cluster configuration file, execute the following command: If you have created or edited a configuration file on a local node, use the following command to send that file to one of the nodes in the cluster: To verify that all of the nodes specified in the local file have the identical cluster configuration file, execute the following command:

Commands:
ccs -h host --sync --activate
ccs -h host --checkconf
ccs -f file -h host --setconf
ccs -f file --checkconf
Chapter 8. Ceph File System snapshots As a storage administrator, you can take a point-in-time snapshot of a Ceph File System (CephFS) directory. CephFS snapshots are asynchronous, and you can choose which directory snapshots are created in. Prerequisites A running, and healthy Red Hat Ceph Storage cluster. Deployment of a Ceph File System. 8.1. Ceph File System snapshots The Ceph File System (CephFS) snapshotting feature is enabled by default on new Ceph File Systems, but must be manually enabled on existing Ceph File Systems. CephFS snapshots create an immutable, point-in-time view of a Ceph File System. CephFS snapshots are asynchronous and are kept in a special hidden directory in the CephFS directory named .snap . You can specify snapshot creation for any directory within a Ceph File System. When specifying a directory, the snapshot also includes all the subdirectories beneath it. Warning Each Ceph Metadata Server (MDS) cluster allocates the snap identifiers independently. Using snapshots for multiple Ceph File Systems that are sharing a single pool causes snapshot collisions, and results in missing file data. Additional Resources See the Creating a snapshot for a Ceph File System section in the Red Hat Ceph Storage File System Guide for more details. See the Creating a snapshot schedule for a Ceph File System section in the Red Hat Ceph Storage File System Guide for more details. 8.2. Creating a snapshot for a Ceph File System You can create an immutable, point-in-time view of a Ceph File System (CephFS) by creating a snapshot. Note For a new Ceph File System, snapshots are enabled by default. Prerequisites A running, and healthy Red Hat Ceph Storage cluster. Deployment of a Ceph File System. Root-level access to a Ceph Metadata Server (MDS) node. Procedure Log into the Cephadm shell: Example For existing Ceph File Systems, enable the snapshotting feature: Syntax Example Create a new snapshot subdirectory under the .snap directory: Syntax Example This example creates the new-snaps subdirectory, and this informs the Ceph Metadata Server (MDS) to start making snapshots. To delete snapshots: Syntax Example Important Attempting to delete root-level snapshots, which might contain underlying snapshots, will fail. Additional Resources See the Ceph File System snapshot schedules section in the Red Hat Ceph Storage File System Guide for more details. See the Ceph File System snapshots section in the Red Hat Ceph Storage File System Guide for more details. See the Deployment of the Ceph File System section in the Red Hat Ceph Storage File System Guide .

Commands:
cephadm shell
ceph fs set FILE_SYSTEM_NAME allow_new_snaps true
ceph fs set cephfs01 allow_new_snaps true
mkdir NEW_DIRECTORY_PATH
mkdir /.snap/new-snaps
rmdir NEW_DIRECTORY_PATH
rmdir /.snap/new-snaps
7.303. crash-gcore-command 7.303.1. RHBA-2013:1102 - crash-gcore-command bug fix update Updated crash-gcore-command packages that fix one bug are now available for Red Hat Enterprise Linux 6. The crash-gcore-command packages contain an extension module for the crash utility that adds a "gcore" command which can create a core dump file of a user-space task that was running in a kernel dumpfile. Bug Fix BZ# 968897 VDSO and vsyscall pages are not contained in the generated process core dump, due to a backported madvise/MADV_DONTDUMP change in the Red Hat Enterprise Linux 6 kernel. With this update, the VDSO and vsyscall pages are contained in the generated core dump. Users of crash-gcore-command are advised to upgrade to these updated packages, which fix this bug.

Commands:
probe::ipmib.InAddrErrors Name probe::ipmib.InAddrErrors - Count arriving packets with an incorrect address Synopsis ipmib.InAddrErrors Values skb pointer to the struct sk_buff being acted on op value to be added to the counter (default value of 1) Description The packet pointed to by skb is filtered by the function ipmib_filter_key . If the packet passes the filter is is counted in the global InAddrErrors (equivalent to SNMP's MIB IPSTATS_MIB_INADDRERRORS)

Commands:
Chapter 2. Managed broker configuration When you deploy Streams for Apache Kafka on OpenShift, you specify broker configuration through the config property of the Kafka custom resource. However, certain broker configuration options are managed directly by Streams for Apache Kafka. As such, if you are using Streams for Apache Kafka on OpenShift, you cannot configure the following options: broker.id to specify the ID of the Kafka broker log.dirs directories for log data zookeeper.connect configuration to connect Kafka with ZooKeeper listeners to expose the Kafka cluster to clients authorization mechanisms to allow or decline actions executed by users authentication mechanisms to prove the identity of users requiring access to Kafka Broker IDs start from 0 (zero) and correspond to the number of broker replicas. Log directories are mounted to /var/lib/kafka/data/kafka-log IDX based on the spec.kafka.storage configuration in the Kafka custom resource. IDX is the Kafka broker pod index. For a list of exclusions, see the KafkaClusterSpec schema reference . These exclusions don't apply when using Streams for Apache Kafka on RHEL. In this case, you need to add these properties in your basic broker configuration to identify your brokers and provide secure access. Example broker configuration for Streams for Apache Kafka on RHEL # ... broker.id = 1 log.dirs = /var/lib/kafka zookeeper.connect = zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181 listeners = internal-1://:9092 authorizer.class.name = kafka.security.auth.SimpleAclAuthorizer ssl.truststore.location = /path/to/truststore.jks ssl.truststore.password = 123456 ssl.client.auth = required # ... Additional resources Configuring Kafka on OCP Using Streams for Apache Kafka on RHEL in KRaft mode Using Streams for Apache Kafka on RHEL with ZooKeeper

Commands:
broker.id = 1 log.dirs = /var/lib/kafka zookeeper.connect = zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181 listeners = internal-1://:9092 authorizer.class.name = kafka.security.auth.SimpleAclAuthorizer ssl.truststore.location = /path/to/truststore.jks ssl.truststore.password = 123456 ssl.client.auth = required
Chapter 1. Overview of Builds Builds is an extensible build framework based on the Shipwright project , which you can use to build container images on an OpenShift Container Platform cluster. You can build container images from source code and Dockerfiles by using image build tools, such as Source-to-Image (S2I) and Buildah. You can create and apply build resources, view logs of build runs, and manage builds in your OpenShift Container Platform namespaces. Builds includes the following capabilities: Standard Kubernetes-native API for building container images from source code and Dockerfiles Support for Source-to-Image (S2I) and Buildah build strategies Extensibility with your own custom build strategies Execution of builds from source code in a local directory Shipwright CLI for creating and viewing logs, and managing builds on the cluster Integrated user experience with the Developer perspective of the OpenShift Container Platform web console Note Because Builds releases on a different cadence from OpenShift Container Platform, the Builds documentation is now available as a separate documentation set at builds for Red Hat OpenShift .

Commands:
5.5. Booleans Booleans allow parts of SELinux policy to be changed at runtime, without any knowledge of SELinux policy writing. This allows changes, such as allowing services access to NFS volumes, without reloading or recompiling SELinux policy. 5.5.1. Listing Booleans For a list of Booleans, an explanation of what each one is, and whether they are on or off, run the semanage boolean -l command as the Linux root user. The following example does not list all Booleans: The SELinux boolean column lists Boolean names. The Description column lists whether the Booleans are on or off, and what they do. In the following example, the ftp_home_dir Boolean is off, preventing the FTP daemon ( vsftpd ) from reading and writing to files in user home directories: The getsebool -a command lists Booleans, whether they are on or off, but does not give a description of each one. The following example does not list all Booleans: Run the getsebool boolean-name command to only list the status of the boolean-name Boolean: Use a space-separated list to list multiple Booleans:

Commands:
~]# semanage boolean -l SELinux boolean Description ftp_home_dir -> off Allow ftp to read and write files in the user home directories xen_use_nfs -> off Allow xen to manage nfs files xguest_connect_network -> on Allow xguest to configure Network Manager
ftp_home_dir -> off Allow ftp to read and write files in the user home directories
~]USD getsebool -a allow_console_login --> off allow_cvs_read_shadow --> off allow_daemons_dump_core --> on
~]USD getsebool allow_console_login allow_console_login --> off
~]USD getsebool allow_console_login allow_cvs_read_shadow allow_daemons_dump_core allow_console_login --> off allow_cvs_read_shadow --> off allow_daemons_dump_core --> on
5.272. quota 5.272.1. RHBA-2012:1472 - quota bug fix update Updated quota packages that fix multiple bugs are now available for Red Hat Enterprise Linux 6. The quota packages contain a suite of system administration tools for monitoring and limiting user and group disk usage on file systems. Bug Fixes BZ# 680919 Prior to this update, warnquota sent emails from <root@myhost.com> if the quota limit was exceeded and the warnquota tool was enabled to send warning emails and the default warnquota configuration was not changed. As a consequence, users could wrongly reply to this address and email bounces were delivered to the mailbox of <root@myhost.com>. This update modifies the default warnquota configuration to use the reserved domain "example.com". BZ# 683554 Prior to this update, the option "-r" for setquota and edquota failed to set the grace times for NFS-mounted file systems without reporting errors because the underlying remote procedure call protocol does not support this option. This update disables the option "-r". With this update, the option to set grace times over the network is disabled and error messages are sent when using the "-r" option. BZ# 692390 Prior to this update, the quotacheck tool could mishandle UIDs in processed fsv1 quota files if a user's block limit was reached. This update zeroes uninitialized padding in the "v2r1 ddquot" structure before running subsequent checks. BZ# 704216 Prior to this update, the edquota tool could abort with a segmentation fault if the name server switch was configured to use the libdb back end. This update modifies the underlying code to make the "dirname" symbol in edquota sources static to avoid pollution of the symbol name space confusing the dynamic linker. Now, edquota runs on systems which use the Berkeley DB (BDB) database for storing user names, group names, or passwords. BZ# 730057 Prior to this update, the quota_nld service logged the error message "Failed to find tty of [UID] to report warning to" when users without an interactive session exceeded the disk quota limit while running quota_nld service. This update applies these warnings to non-daemon debugging mode of quota_nld only. BZ# 770307 Prior to this update, the warnquota tool sent a badly worded email message. This update changes the wording and the text is now worded more representative. All users of quota are advised to upgrade to these updated packages, which fix these bugs.

Commands:
H.4. Virtualization Host Groups A number of system user groups are created on the virtualization host when the vdsm and qemu-kvm-rhev packages are installed. Each system user group has a default group identifier (GID). The system user groups created are: The kvm group (GID 36 ). Group members include: The qemu user. The sanlock user. The qemu group (GID 107 ). Group members include: The vdsm user. The sanlock user. The ovirt-vmconsole group (GID 498 ). Group members include: The ovirt-vmconsole user. Important The user identifiers (UIDs) and group identifiers (GIDs) allocated may vary between systems. The vdsm user is fixed to a UID of 36 and the kvm group is fixed to a GID of 36 . If UID 36 or GID 36 is already used by another account on the system a conflict will arise during installation of the vdsm and qemu-kvm-rhev packages.

Commands:
Chapter 51. 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 . podSet ResourceTemplate Template for ZooKeeper StrimziPodSet resource. 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.

Commands:
Chapter 46. Kafka Topic Name Matches Filter Action Filter based on kafka topic value compared to regex 46.1. Configuration Options The following table summarizes the configuration options available for the topic-name-matches-filter-action Kamelet: Property Name Description Type Default Example regex * Regex The Regex to Evaluate against the Kafka topic name string Note Fields marked with an asterisk (*) are mandatory. 46.2. Dependencies At runtime, the topic-name-matches-filter-action Kamelet relies upon the presence of the following dependencies: camel:core camel:kamelet 46.3. Usage This section describes how you can use the topic-name-matches-filter-action . 46.3.1. Kafka Action You can use the topic-name-matches-filter-action Kamelet as an intermediate step in a Kafka binding. topic-name-matches-filter-action-binding.yaml apiVersion: camel.apache.org/v1alpha1 kind: KameletBinding metadata: name: topic-name-matches-filter-action-binding spec: source: ref: kind: Kamelet apiVersion: camel.apache.org/v1alpha1 name: timer-source properties: message: "Hello" steps: - ref: kind: Kamelet apiVersion: camel.apache.org/v1alpha1 name: topic-name-matches-filter-action properties: regex: "The Regex" sink: ref: kind: KafkaTopic apiVersion: kafka.strimzi.io/v1beta1 name: my-topic 46.3.1.1. Prerequisites Ensure that you've installed the AMQ Streams operator in your OpenShift cluster and created a topic named my-topic in the current namespace. Make also sure you have "Red Hat Integration - Camel K" installed into the OpenShift cluster you're connected to. 46.3.1.2. Procedure for using the cluster CLI Save the topic-name-matches-filter-action-binding.yaml file to your local drive, and then edit it as needed for your configuration. Run the action by using the following command: oc apply -f topic-name-matches-filter-action-binding.yaml 46.3.1.3. Procedure for using the Kamel CLI Configure and run the action by using the following command: kamel bind timer-source?message=Hello --step topic-name-matches-filter-action -p "step-0.regex=The Regex" kafka.strimzi.io/v1beta1:KafkaTopic:my-topic This command creates the KameletBinding in the current namespace on the cluster. 46.4. Kamelet source file https://github.com/openshift-integration/kamelet-catalog/topic-name-matches-filter-action.kamelet.yaml

Commands:
apiVersion: camel.apache.org/v1alpha1 kind: KameletBinding metadata: name: topic-name-matches-filter-action-binding spec: source: ref: kind: Kamelet apiVersion: camel.apache.org/v1alpha1 name: timer-source properties: message: "Hello" steps: - ref: kind: Kamelet apiVersion: camel.apache.org/v1alpha1 name: topic-name-matches-filter-action properties: regex: "The Regex" sink: ref: kind: KafkaTopic apiVersion: kafka.strimzi.io/v1beta1 name: my-topic
apply -f topic-name-matches-filter-action-binding.yaml
kamel bind timer-source?message=Hello --step topic-name-matches-filter-action -p "step-0.regex=The Regex" kafka.strimzi.io/v1beta1:KafkaTopic:my-topic