mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. OpenShift Data Foundation upgrade channels and releases In OpenShift Container Platform 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster upgrades. By controlling the pace of upgrades, these upgrade channels allow you to choose an upgrade strategy. As OpenShift Data Foundation gets deployed as an operator in OpenShift Container Platform, it follows the same strategy to control the pace of upgrades by shipping the fixes in multiple channels. Upgrade channels are tied to a minor version of OpenShift Data Foundation. For example, OpenShift Data Foundation 4.17 upgrade channels recommend upgrades within 4.17. Upgrades to future releases is not recommended. This strategy ensures that administrators can explicitly decide to upgrade to the minor version of OpenShift Data Foundation. Upgrade channels control only release selection and do not impact the version of the cluster that you install; the odf-operator decides the version of OpenShift Data Foundation to be installed. By default, it always installs the latest OpenShift Data Foundation release maintaining the compatibility with OpenShift Container Platform. So, on OpenShift Container Platform 4.17, OpenShift Data Foundation 4.17 will be the latest version which can be installed. OpenShift Data Foundation upgrades are tied to the OpenShift Container Platform upgrade to ensure that compatibility and interoperability are maintained with the OpenShift Container Platform. For OpenShift Data Foundation 4.17, OpenShift Container Platform 4.17 and 4.17 (when generally available) are supported. OpenShift Container Platform 4.17 is supported to maintain forward compatibility of OpenShift Data Foundation with OpenShift Container Platform. Keep the OpenShift Data Foundation version the same as OpenShift Container Platform in order to get the benefit of all the features and enhancements in that release. Important Due to fundamental Kubernetes design, all OpenShift Container Platform updates between minor versions must be serialized. You must update from OpenShift Container Platform 4.15 to 4.16 and then to 4.17. You cannot update from OpenShift Container Platform 4.16 to 4.17 directly. For more information, see Preparing to perform an EUS-to-EUS update of the Updating clusters guide in OpenShift Container Platform documentation. OpenShift Data Foundation 4.17 offers the following upgrade channel: stable-4.17 stable-4.16 stable-4.17 channel Once a new version is Generally Available, the stable channel corresponding to the minor version gets updated with the new image which can be used to upgrade. You can use the stable-4.17 channel to upgrade from OpenShift Data Foundation 4.16 and upgrades within 4.17. stable-4.16 You can use the stable-4.16 channel to upgrade from OpenShift Data Foundation 4.15 and upgrades within 4.16.

Commands:
10.3.6. Other Partitioning Problems If you create partitions manually, but cannot move to the screen, you probably have not created all the partitions necessary for installation to proceed. You must have the following partitions as a bare minimum: A / (root) partition A <swap> partition of type swap Refer to Section 9.15.5, "Recommended Partitioning Scheme" for more information. Note When defining a partition's type as swap, do not assign it a mount point. Anaconda automatically assigns the mount point for you.

Commands:
5.3.5. Displaying Volume Groups There are two commands you can use to display properties of LVM volume groups: vgs and vgdisplay . The vgscan command, which scans all the disks for volume groups and rebuilds the LVM cache file, also displays the volume groups. For information on the vgscan command, see Section 5.3.6, "Scanning Disks for Volume Groups to Build the Cache File" . The vgs command provides volume group information in a configurable form, displaying one line per volume group. The vgs command provides a great deal of format control, and is useful for scripting. For information on using the vgs command to customize your output, see Section 5.8, "Customized Reporting for LVM" . The vgdisplay command displays volume group properties (such as size, extents, number of physical volumes, and so on) in a fixed form. The following example shows the output of a vgdisplay command for the volume group new_vg . If you do not specify a volume group, all existing volume groups are displayed.

Commands:
vgdisplay new_vg --- Volume group --- VG Name new_vg System ID Format lvm2 Metadata Areas 3 Metadata Sequence No 11 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 3 Act PV 3 VG Size 51.42 GB PE Size 4.00 MB Total PE 13164 Alloc PE / Size 13 / 52.00 MB Free PE / Size 13151 / 51.37 GB VG UUID jxQJ0a-ZKk0-OpMO-0118-nlwO-wwqd-fD5D32
6.2. TPS Operations Explicit Operations An explicit operation is an operation called by a user. Explicit operations include enroll ( op.enroll.* ), format ( op.format.* ), and pinReset ( op.pinReset.* ). Implicit Operations An implicit operation is an operation that takes place due to the policy or status of a token at a time when an explicit operation is being processed. Implicit operations include keyGen ( op.enroll.userKey.keyGen.* ), renewal ( op.enroll.userKey.renewal.* ), update.applet ( op.enroll.userKey.update.applet.* ), and key update ( op.enroll.userKey.update.symmetricKeys.* ). Some implicit operations are controlled per key type. These include recovery , serverKeygen , and revocation . The following example of a TPS profile specifies user keys to be generated on the server side: Additionally, the following example tells TPS that a token whose keys are compromised should revoke the certification with revocation reason 1 during the state transition: According to RFC 5280, possible revocation reasons and their codes are defined as follows: Table 6.1. Revocation Reasons and Codes Reason Code unspecified 0 keyCompromise 1 CACompromise 2 affiliationChanged 3 superseded 4 cessationOfOperation 5 certificateHold 6 removeFromCRL 8 privilegeWithdrawn 9 AACompromise 10

Commands:
op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1 op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert=true op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert.reason=1
Chapter 86. KafkaClientAuthenticationScramSha512 schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationScramSha512 schema properties To configure SASL-based SCRAM-SHA-512 authentication, set the type property to scram-sha-512 . The SCRAM-SHA-512 authentication mechanism requires a username and password. Example SASL-based SCRAM-SHA-512 client authentication configuration for Kafka Connect authentication: type: scram-sha-512 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field In the passwordSecret property, specify a link to a Secret containing the password. You can use the secrets created by the User Operator. If required, you can create a text file that contains the password, in cleartext, to use for authentication: echo -n <password> > <my_password>.txt You can then create a Secret from the text file, setting your own field name (key) for the password: oc create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt Example secret for SCRAM-SHA-512 client authentication for Kafka Connect apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm The secretName property contains the name of the Secret , and the password property contains the name of the key under which the password is stored inside the Secret . Important Do not specify the actual password in the password property. 86.1. KafkaClientAuthenticationScramSha512 schema properties Property Property type Description type string Must be scram-sha-512 . username string Username used for the authentication. passwordSecret PasswordSecretSource Reference to the Secret which holds the password.

Commands:
authentication: type: scram-sha-512 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field
echo -n <password> > <my_password>.txt
create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm
8.223. spice-vdagent 8.223.1. RHBA-2014:1578 - spice-vdagent bug fix update Updated spice-vdagent packages that fix one bug are now available for Red Hat Enterprise Linux 6. The spice-vdagent packages provide a SPICE agent for Linux guests. Bug Fix BZ# 1066094 When using Eclipse within a Red Hat Enterprise Linux 6 guest in Virtual Desktop Infrastructure, the digit displaying the number of hidden tabs or within was rendered incorrectly. This bug has been fixed, and the text is now rendered normally, keeping the physical screen size to a constant 96 DPI. Users of spice-vdagent are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 2. Ansible rulebooks Event-Driven Ansible controller provides the interface in which Event-Driven Ansible automation performs. Ansible rulebook provides the framework for Event-Driven Ansible automation. Ansible rulebook is essentially a collection of rulesets, which in turn, consists of one or more sources, rules, and conditions. 2.1. Decision Environments Event-Driven Ansible includes, by default, an ansible.eda collection, which contains sample sources, event filters and rulebooks. All the collections, ansible rulebooks and their dependencies use a Decision Environment, which is an image that can be run on either Podman or Kubernetes. In Decision Environments, sources, which are typically Python code, are distributed through ansible-collections. They inject external events into a rulebook for processing. The rulebook consists of the following: The python interpreter Java Runtime Environment for Drools rule engine ansible-rulebook python package ansible.eda collection You can use the base Decision Environment and build your own customized Decision Environments with additional collections and collection dependencies. You can build a Decision Environment using a Dockerfile or optionally you can deploy your CA certificate into the image. 2.2. Rulebook actions A rulebook specifies actions to be performed when a rule is triggered. A rule gets triggered when the events match the conditions for the rules. The following actions are currently supported: run_job_template run_playbook (only supported with ansible-rulebook CLI) debug print_event set_fact post_event retract_fact shutdown Additional resources For more information on using rulebooks, see the Event-Driven Ansible controller User's Guide . For more detailed information on Ansible rulebooks, see the section on Rulebooks in the Ansible Rulebook documentation .

Commands:
3.2. Converting Software Collection Scriptlets into Environment Modules Environment modules allow you to manage, for example, different versions of applications by dynamically modifying your shell environment. To use your Software Collection with the environment module system, convert the Software Collection's enable scriptlet into an environment module with a script /usr/share/Modules/bin/createmodule.sh . Procedure 3.1. Converting an enable scriptlet into an environment module Ensure that an environment-modules package is installed on your system: Run the /usr/share/Modules/bin/createmodule.sh script to convert your Software Collection's enable scriptlet into an environment module: Replace /path/to/enable/scriptlet with the file path of the enable scriptlet you want to convert. Add the same command /usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet in the %pre section of your Software Collection metapackage, below the code generating your enable scriptlet. In case you have the enable scriptlet packaged as a file in one of your Software Collection packages, add the command /usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet in the %post section. See the module (1) man page for more information about environment modules.

Commands:
yum install environment-modules
/usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet
Chapter 2. Image Registry Operator in OpenShift Dedicated 2.1. Image Registry on OpenShift Dedicated The Image Registry Operator installs a single instance of the OpenShift image registry, and manages all registry configuration, including setting up registry storage. After the control plane deploys in the management cluster, the Operator creates a default configs.imageregistry.operator.openshift.io resource instance based on configuration detected in the cluster. If insufficient information is available to define a complete configs.imageregistry.operator.openshift.io resource, the incomplete resource is defined and the Operator updates the resource status with information about what is missing.

Commands:
8.53. evolution 8.53.1. RHBA-2014:1416 - evolution bug fix update Updated evolution packages that fix several bugs are now available for Red Hat Enterprise Linux 6. Evolution is a GNOME application that provides integrated email, calendar, contact management and communications functionality. The components which make up Evolution are tightly integrated with one another and act as a seamless personal information-management (PIM) tool. Bug Fixes BZ# 1052955 Previously, the option to choose the time format in the Evolution application was not offered for certain languages. As a consequence, the calendar component editor always showed time in the 24-hour format. With this update, the correct time format is displayed based on the selection the user makes in the Edit menu: Preferences, Calendar and Tasks. BZ# 1054772 Prior to this update, newly created local address books were not set correctly. Consequently, address books in the Evolution application could not be deleted, and incorrect data was displayed. With this update, address books can be removed, contacts in separated address books remain visible only in the appropriate address books, and the add, edit, and remove operations no longer cause any inconsistency. BZ# 1054865 Previously, the Evolution application did not always handle adding new attachments correctly. As a consequence, attaching a large file caused the Evolution application to terminate unexpectedly under certain circumstances. A patch has been applied to address this bug, and adding new attachments no longer causes Evolution to crash. BZ# 1070846 Previously, the Evolution application displayed only a general prompt for the Smart Card PIN. As a consequence, the user could be uncertain what PIN to enter. This update improves the prompt, and the user now knows what certificate the requested PIN belongs to. BZ# 1080467 Prior to this update, the Evolution application did not correctly handle calling the "Mark All As Read" function. Consequently, Evolution could become unresponsive until the operation was completely finished. A patch has been provided to fix this problem, and Evolution no longer hangs in the described situation. BZ# 1139166 Previously, an error could occur when displaying a new email notification. As a consequence, the Evolution application did not work correctly under certain circumstances. With this update, the bug has been fixed and email notifications are correctly displayed. Users of evolution are advised to upgrade to these updated packages, which fix these bugs. All running instances of Evolution must be restarted for this update to take effect.

Commands:
9.2. NUMA Memory Allocation Policies The following policies define how memory is allocated from the nodes in a system: Strict Strict policy means that the allocation will fail if the memory cannot be allocated on the target node. Specifying a NUMA nodeset list without defining a memory mode attribute defaults to strict mode. Interleave Memory pages are allocated across nodes specified by a nodeset, but are allocated in a round-robin fashion. Preferred Memory is allocated from a single preferred memory node. If sufficient memory is not available, memory can be allocated from other nodes. To enable the desired policy, set it as the value of the <memory mode> element of the domain XML file: <numatune> <memory mode=' preferred ' nodeset='0'> </numatune> Important If memory is overcommitted in strict mode and the guest does not have sufficient swap space, the kernel will kill some guest processes to retrieve additional memory. Red Hat recommends using preferred allocation and specifying a single nodeset (for example, nodeset='0') to prevent this situation.

Commands:
<numatune> <memory mode=' preferred ' nodeset='0'> </numatune>
1.4. The Cluster and Pacemaker Configuration Files The configuration files for the Red Hat High Availability add-on are corosync.conf and cib.xml . The corosync.conf file provides the cluster parameters used by corosync , the cluster manager that Pacemaker is built on. In general, you should not edit the corosync.conf directly but, instead, use the pcs or pcsd interface. However, there may be a situation where you do need to edit this file directly. For information on editing the corosync.conf file, see Editing the corosync.conf file in Red Hat Enterprise Linux 7 . The cib.xml file is an XML file that represents both the cluster's configuration and current state of all resources in the cluster. This file is used by Pacemaker's Cluster Information Base (CIB). The contents of the CIB are automatically kept in sync across the entire cluster Do not edit the cib.xml file directly; use the pcs or pcsd interface instead.

Commands:
1.2. GFS Functions GFS is a native file system that interfaces directly with the VFS layer of the Linux kernel file-system interface. GFS is a cluster file system that employs distributed metadata and multiple journals for optimal operation in a cluster. Cluster management of GFS nodes is managed through Red Hat Cluster Suite. Volume management is managed through CLVM (Cluster Logical Volume Manager). For information about Red Hat Cluster Suite refer to Configuring and Managing a Red Hat Cluster . For information about using CLVM, refer to LVM Administrator's Guide . Note CLVM is a cluster-wide implementation of LVM, enabled by the CLVM daemon, clvmd running in a Red Hat Cluster Suite cluster. The daemon makes it possible to use LVM2 to manage logical volumes across a cluster, allowing all nodes in the cluster to share the logical volumes. GFS provides the following main functions: Making a File System Mounting a File System Unmounting a File System GFS Quota Management Growing a File System Adding Journals to a File System Direct I/O Data Journaling Configuring atime Updates Suspending Activity on a File System Displaying Extended GFS Information and Statistics Repairing a File System Context-Dependent Path Names (CDPN)

Commands:
Chapter 9. Troubleshooting Satellite by using Hammer You can use the hammer ping command to check the status of core Satellite services. Together with the satellite-maintain service status command, this can help you to diagnose and troubleshoot Satellite issues. If all services are running as expected, the output looks as follows:

Commands:
hammer ping database: Status: ok Server Response: Duration: 0ms cache: servers: 1) Status: ok Server Response: Duration: 1ms candlepin: Status: ok Server Response: Duration: 17ms candlepin_auth: Status: ok Server Response: Duration: 14ms candlepin_events: Status: ok message: 4 Processed, 0 Failed Server Response: Duration: 0ms katello_events: Status: ok message: 5 Processed, 0 Failed Server Response: Duration: 0ms pulp3: Status: ok Server Response: Duration: 5083ms pulp3_content: Status: ok Server Response: Duration: 5051ms foreman_tasks: Status: ok Server Response: Duration: 2ms
Chapter 1. Red Hat Ansible Automation Platform installation overview The Red Hat Ansible Automation Platform installation program offers you flexibility, allowing you to install Ansible Automation Platform by using several supported installation scenarios. Regardless of the installation scenario you choose, installing Ansible Automation Platform involves the following steps: Editing the Red Hat Ansible Automation Platform installer inventory file The Ansible Automation Platform installer inventory file allows you to specify your installation scenario and describe host deployments to Ansible. The examples provided in this document show the parameter specifications needed to install that scenario for your deployment. Running the Red Hat Ansible Automation Platform installer setup script The setup script installs Ansible Automation Platform by using the required parameters defined in the inventory file. Verifying your Ansible Automation Platform installation After installing Ansible Automation Platform, you can verify that the installation has been successful by logging in to the platform UI and seeing the relevant functionality. Additional resources For more information about the supported installation scenarios, see the Planning your installation . For more information on available topologies, see Tested deployment models . 1.1. Prerequisites You chose and obtained a platform installer from the Red Hat Ansible Automation Platform Product Software . You are installing on a machine that meets base system requirements. You have updated all of the packages to the recent version of your RHEL nodes. Warning To prevent errors, upgrade your RHEL nodes fully before installing Ansible Automation Platform. You have created a Red Hat Registry Service Account, by using the instructions in Creating Registry Service Accounts . Additional resources For more information about obtaining a platform installer or system requirements, see the System requirements in the Planning your installation .

Commands:
Chapter 1. Business processes A business process is a diagram that describes the order for a series of steps that must be executed and consists of predefined nodes and connections. Each node represents one step in the process while the connections specify how to transition from one node to another. A typical business process consists of the following components: The header section that comprises global elements such as the name of the process, imports, and variables The nodes section that contains all the different nodes that are part of the process The connections section that links these nodes to each other to create a flow chart Figure 1.1. Business process Red Hat Process Automation Manager contains the legacy process designer and the new process designer for creating business process diagrams. The new process designer has an improved layout and feature set and continues to be developed. Until all features of the legacy process designer are completely implemented in the new process designer, both designers are available in Business Central for you to use. Note The legacy process designer in Business Central is deprecated in Red Hat Process Automation Manager 7.13.5. It will be removed in a future Red Hat Process Automation Manager release. The legacy process designer will not receive any new enhancements or features. If you intend to use the new process designer, start migrating your processes to the new designer. Create all new processes in the new process designer. For information about migrating to the new designer, see Managing projects in Business Central .

Commands: