mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. 25 October 2023 8.1. Components The following components are available for using Red Hat Ansible Lightspeed: Ansible Extension for VS Code v2.8.108 Ansible code bot Technical Preview This release includes several enhancements, additions, and fixes that have been implemented in Red Hat Ansible Lightspeed. 8.2. New features and enhancements Ansible-specific IBM watsonx Code Assistant models Red Hat Ansible Lightspeed with IBM watsonx Code Assistant uses Ansible-specific IBM watsonx Granite models unique to your organization, which are provided, managed, and maintained by IBM. Single tasks and multitask generation Using natural language prompts, you can generate single task or multiple task recommendations for Ansible task files and playbooks. Content source matching For each generated code recommendation, Red Hat Ansible Lightspeed lists content source matches, including details such as potential source, content author, and relevant licenses. You can use this data to gain insight into potential training data sources used to generate the code recommendations. Post-processing capabilities Red Hat Ansible Lightspeed offers post-processing capabilities that augment IBM watsonx Code Assistant and improve the quality and accuracy of code recommendations. Content modernization The Ansible code bot scans existing content collections, roles, and playbooks through Git repositories, and proactively creates pull requests whenever best practices or quality improvement recommendations are available. The bot automatically submits pull requests to the repository, which proactively alerts the repository owner to a recommended change to their content. Ansible code bot is available as a Technical Preview. For more information, see the Red Hat Ansible Lightspeed with IBM watsonx Code Assistant User Guide .

Commands:
Chapter 3. How does simple content access change subscription tools and workflows? Simple content access is designed to improve the overall customer subscription experience by eliminating cumbersome and confusing parts of the subscription management workflow. With simple content access enabled, that action changes not only the user workflows that manage your subscriptions and provide access to content, but it also changes the way that the various subscription tools themselves operate. These tools include Red Hat Satellite, Red Hat Subscription Management, the subscription-manager command line tool, activation keys, virt-who, and others. For the most recent information that describes the differences between the old entitlement-based workflow and the simple content access workflow, see the information about operational changes in the Simple Content Access Red Hat Customer Portal article.

Commands:
Chapter 7. Backup and disaster recovery This section describes aspects of the CodeReady Workspaces backup and disaster recovery. External database setup Persistent Volumes backups 7.1. External database setup The PostgreSQL database is used by the CodeReady Workspaces server for persisting data about the state of CodeReady Workspaces. It contains information about user accounts, workspaces, preferences, and other details. By default, the CodeReady Workspaces Operator creates and manages the database deployment. However, the CodeReady Workspaces Operator does not support full life-cycle capabilities, such as backups and recovery. For a business-critical setup, configure an external database with the following recommended disaster-recovery options: High Availability (HA) Point In Time Recovery (PITR) When using an external PostgreSQL database, it is also necessary to use an external RH-SSO. Configure an external PostgreSQL instance on-premises or use a cloud service, such as Amazon Relational Database Service (Amazon RDS). With Amazon RDS, it is possible to deploy production databases in a Multi-Availability Zone configuration for a resilient disaster recovery strategy with daily and on-demand snapshots. The recommended configuration of the example database is: Parameter Value Instance class db.t2.small vCPU 1 RAM 2 GB Multi-az true, 2 replicas Engine version 9.6.11 TLS enabled Automated backups enabled (30 days) To make the Operator skip deploying a database and pass connection details of an existing database to a CodeReady Workspaces server using chePostgresHostName , chePostgresPort , chePostgresUser , chePostgresPassword , chePostgresDb parameters, specify the externalDb: true property in the CodeReady Workspaces Custom Resource. Additional resources PostgreSQL RDS 7.2. Persistent Volumes backups Persistent Volumes (PVs) store the CodeReady Workspaces workspace data similarly to how workspace data is stored for desktop IDEs on the local hard disk drive. To prevent data loss, back up PVs periodically. The recommended approach is to use storage-agnostic tools for backing up and restoring OpenShift resources, including PVs. 7.2.1. Recommended backup tool: Velero Velero is an open-source tool for backing up OpenShift applications and their PVs. Velero allows you to: Deploy in the cloud or on premises. Back up the cluster and restore in case of data loss. Migrate cluster resources to other clusters. Replicate a production cluster to development and testing clusters. Note Alternatively, you can use backup solutions dependent on the underlying storage system. For example, solutions that are Gluster or Ceph-specific. Additional resources Persistent Volumes documentation Gluster documentation Ceph documentation Velero on GitHub

Commands:
Chapter 1. Architectures Red Hat Enterprise Linux 7.2 is available as a single kit on the following architectures: [1] 64-bit AMD 64-bit Intel IBM POWER7+ and POWER8 (big endian) [2] IBM POWER8 (little endian) [3] IBM System z [4] [1] Note that the Red Hat Enterprise Linux 7.2 installation is supported only on 64-bit hardware. Red Hat Enterprise Linux 7.2 is able to run 32-bit operating systems, including versions of Red Hat Enterprise Linux, as virtual machines. [2] Red Hat Enterprise Linux 7.2 (big endian) is currently supported as a KVM guest on Red Hat Enterprise Virtualization for Power and on PowerVM. [3] Red Hat Enterprise Linux 7.2 (little endian) is currently supported as a KVM guest on Red Hat Enterprise Virtualization for Power, on PowerVM and PowerNV (bare metal). [4] Note that Red Hat Enterprise Linux 7.2 supports IBM zEnterprise 196 hardware or later; IBM System z10 mainframe systems are no longer supported and will not boot Red Hat Enterprise Linux 7.2.

Commands:
Chapter 7. Migrating custom themes 7.1. New Admin Console The new Admin Console (keycloak.v2) is built using React. The old Admin Console (keycloak) was built with AngularJS 1.x, which reached end-of-life a while ago. Thus, there is no migration path from the old console or any theme that extends it. The base theme Admin Console is also not supported for the same reason. 7.2. New Account Console The new Account Console (keycloak.v2) is built using React, providing a better user experience. The old Account Console (keycloak) was built with basic server-side templating. Thus, there is no migration path from the old console or any theme that extends it. 7.3. Migrating login themes Themes are used to configure the look and feel of login pages and the Account Console. When creating or updating custom themes, especially when overriding templates, it may be useful to use the built-in templates as a reference. These templates are in USD{KC_HOME}/lib/lib/main/org.keycloak.keycloak-themes-USD{KC_VERSION}.jar , which can be opened using any standard ZIP archive tool. When running the server in development mode using start-dev , themes are not cached so that you can easily work on them without a need to restart the server when making changes. To install custom themes, you can choose from packaging your theme files as a JAR file and deploy it to the USD{KC_HOME}/providers directory, or copy files directly to the USD{KC_HOME}/themes directory. In both cases, see the Server Developer Guide for more details about the file and directory structure expected by the server.

Commands:
Appendix C. LDAP URLs LDAP URLs identify the Red Hat Directory Server instance, similarly to the way site URLs identify a specific website or web page. There are three common times when the LDAP URL of the Directory Server instance is used: The LDAP URL is used to identify the specific Directory Server instance when the Directory Server is accessed using a web-based client. LDAP URLs are used to configure Directory Server referrals. LDAP URLs are used to configure access control instructions. Note The LDAP URL format is described in RFC 4516, which is available at http://www.ietf.org/rfc/rfc4516.txt . C.1. Components of an LDAP URL It is also possible to use IPv4 or IPv6 addresses instead of the host name. The ldap:// protocol is used to connect to LDAP servers over unsecured connections, and the ldaps:// protocol is used to connect to LDAP servers over TLS connections. Table C.1, "LDAP URL Components" lists the components of an LDAP URL. Note The LDAP URL format is described in RFC 4516, which is available at http://www.ietf.org/rfc/rfc4516.txt . Table C.1. LDAP URL Components Component Description host name Name, IPv4, o r IPv6 address of the LDAP server. For example, ldap.example.com , 192.0.2.90 , or [2001:db8::1]. port Port number of the LDAP server (for example, 696 ). If no port is specified, the standard LDAP port ( 389 ) or LDAPS port ( 636 ) is used. base_dn Distinguished name (DN) of an entry in the directory. This DN identifies the entry that is the starting point of the search. If no base DN is specified, the search starts at the root of the directory tree. attributes The attributes to be returned. To specify more than one attribute, use commas to separate the attributes; for example, cn,mail,telephoneNumber . If no attributes are specified in the URL, all attributes are returned. scope The scope of the search, which can be one of these values: base retrieves information only about the distinguished name ( base_dn ) specified in the URL. one retrieves information about entries one level below the distinguished name ( base_dn ) specified in the URL. The base entry is not included in this scope. sub retrieves information about entries at all levels below the distinguished name ( base_dn ) specified in the URL. The base entry is included in this scope. If no scope is specified, the server performs a base search. filter Search filter to apply to entries within the specified scope of the search. If no filter is specified, the server uses the filter (objectClass=*) . The attributes, scope, and filter components are identified by their positions in the URL. Even if no attributes are specified, the question marks still must be included to delimit that field. For example, to specify a subtree search starting from dc=example,dc=com that returns all attributes for entries matching (sn=Jensen) , use the following LDAP URL: The two consecutive question marks, ?? , indicate that no attributes have been specified. Since no specific attributes are identified in the URL, all attributes are returned in the search.

Commands:
ldap[s]:// hostname:port/base_dn?attributes?scope?filter
ldap://ldap.example.com/dc=example,dc=com??sub?(sn=Jensen)
7.8. Duplicate PV Warnings for Multipathed Devices When using LVM with multipathed storage, some LVM commands (such as vgs or lvchange ) may display messages such as the following when listing a volume group or logical volume. After providing information on the root cause for these warnings, this section describes how to address this issue in the following two cases. The two devices displayed in the output are both single paths to the same device The two devices displayed in the output are both multipath maps 7.8.1. Root Cause of Duplicate PV Warning With a default configuration, LVM commands will scan for devices in /dev and check every resulting device for LVM metadata. This is caused by the default filter in the /etc/lvm/lvm.conf , which is as follows: When using Device Mapper Multipath or other multipath software such as EMC PowerPath or Hitachi Dynamic Link Manager (HDLM), each path to a particular logical unit number (LUN) is registered as a different SCSI device, such as /dev/sdb or /dev/sdc . The multipath software will then create a new device that maps to those individual paths, such as /dev/mapper/mpath1 or /dev/mapper/mpatha for Device Mapper Multipath, /dev/emcpowera for EMC PowerPath, or /dev/sddlmab for Hitachi HDLM. Since each LUN has multiple device nodes in /dev that point to the same underlying data, they all contain the same LVM metadata and thus LVM commands will find the same metadata multiple times and report them as duplicates. These duplicate messages are only warnings and do not mean the LVM operation has failed. Rather, they are alerting the user that only one of the devices has been used as a physical volume and the others are being ignored. If the messages indicate the incorrect device is being chosen or if the warnings are disruptive to users, then a filter can be applied to search only the necessary devices for physical volumes, and to leave out any underlying paths to multipath devices.

Commands:
Found duplicate PV GDjTZf7Y03GJHjteqOwrye2dcSCjdaUi: using /dev/dm-5 not /dev/sdd Found duplicate PV GDjTZf7Y03GJHjteqOwrye2dcSCjdaUi: using /dev/emcpowerb not /dev/sde Found duplicate PV GDjTZf7Y03GJHjteqOwrye2dcSCjdaUi: using /dev/sddlmab not /dev/sdf
filter = [ "a/.*/" ]
Chapter 6. Logging 6.1. Overview of Logging JBoss EAP 6 provides highly configurable logging facilities for both its own internal use and for use by deployed applications. The logging subsystem is based on JBoss LogManager and it supports several third party application logging frameworks in addition to JBoss Logging. The logging subsystem is configured using a system of log categories and log handlers. Log categories define what messages to capture, and log handlers define how to deal with those messages (write to disk, send to console etc). Logging Profiles allow uniquely named sets of logging configuration to be created and assigned to applications independent of any other logging configuration. The configuration of logging profiles is almost identical to the main logging subsystem.

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ OpenWire JMS examples require a running message broker with a queue named exampleQueue . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named exampleQueue . USD <broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-05-07 10:16:37 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
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.15 upgrade channels recommend upgrades within 4.15. 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.15, OpenShift Data Foundation 4.15 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.15, OpenShift Container Platform 4.15 and 4.15 (when generally available) are supported. OpenShift Container Platform 4.15 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.13 to 4.14 and then to 4.15. You cannot update from OpenShift Container Platform 4.13 to 4.15 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.15 offers the following upgrade channel: stable-4.15 stable-4.14 stable-4.15 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.15 channel to upgrade from OpenShift Data Foundation 4.14 and upgrades within 4.15. stable-4.14 You can use the stable-4.14 channel to upgrade from OpenShift Data Foundation 4.13 and upgrades within 4.14.

Commands:
8.99. iscsi-initiator-utils 8.99.1. RHBA-2014:1580 - iscsi-initiator-utils bug fix and enhancement update Updated iscsi-initiator-utils packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The iscsi-initiator-utils packages provide the server daemon for the Internet Small Computer System Interface (iSCSI) protocol, as well as the utility programs used to manage it. iSCSI is a protocol for distributed disk access using SCSI commands sent over Internet Protocol (IP) networks. The QLogic ala4xxx drivers have been updated to the latest upstream version, which provides a number of bug fixes and enhancements over the version. (BZ# 1053374 , BZ# 1140326 ) This update also fixes the following bugs: Note The iSCSI UserSpace I/O driver (iscsiuio) has been updated to upstream version 0.7.8.2, which provides a number of bug fixes and enhancements over the version. (BZ# 1054587 ) The QLogic ala4xxx drivers have been updated to the latest upstream version, which provides a number of bug fixes and enhancements over the version. (BZ#1053374, BZ#1140326) This update also fixes the following bugs: Bug Fixes BZ# 0009299 , BZ# 1052361 Due to changes in the addressing of inter-process communication (IPC) sockets, updating the isciadm administration utility caused it to be incompatible with the already-running iscsid processes. As a consequence, iscsiadm could no longer communicate with the running iscsid processes after the update. This update adds a retroactive compatibility IPC mode, which automatically triggers when a new IPC socket fails to connect. As a result, iscsiadm can now correctly be used to control pre-existing iscsid processes after an update. BZ# 1132490 Prior to this update, the uip_reset() function was in some cases called with an invalid ustack address. As a consequence, the iscsiuio process was terminated unexpectedly with a segmentation fault. With this update, the ustack address calling uip_reset() has been fixed and the described crash no longer occurs. BZ# 1076344 Prior to this update, the iscsid daemon could not handle more than 31 iSCSI asynchronous events. Consequently, when performing an iSCSI operation with 32 or more target protocol data units, iscsid entered an infinite loop and became unresponsive. With this update, iscsid can properly handle more than 31 iSCSI asynchronous events, and the described hang no longer occurs. The iSCSI UserSpace I/O driver (iscsiuio) has been updated to upstream version 0.7.8.2, which provides a number of bug fixes and enhancements over the version. (BZ#1054587) The QLogic ala4xxx drivers have been updated to the latest upstream version, which provides a number of bug fixes and enhancements over the version. (BZ#1053374, BZ#1140326) Users of iscsi-initiator-utils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands: