mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Installing a three-node cluster on Azure In OpenShift Container Platform version 4.17, you can install a three-node cluster on Microsoft Azure. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. Note Deploying a three-node cluster using an Azure Marketplace image is not supported. 5.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on Azure using ARM templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 5.2. steps Installing a cluster on Azure with customizations Installing a cluster on Azure using ARM templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 1. Compatibility Matrix for Red Hat Ceph Storage 7.0 The following tables list products and their versions compatible with Red Hat Ceph Storage 7.0. Host Operating System Version Red Hat Enterprise Linux 9.2 Standard lifecycle 9.2 is included in the product. Important All nodes in the cluster and their clients must use the supported OS version(s) to ensure that the version of the ceph package is the same on all nodes. Using different versions of the ceph package is not supported. Important Ubuntu is not supported as a deploying host operating system. Product Version Notes Ansible Supported in a limited capacity. Supported for upgrade and conversion to Cephadm and for other minimal playbooks. Red Hat OpenShift Data Foundation See the Red Hat OpenShift Data Foundation Supportability and Interoperability Checker for detailed external mode version compatibility. Red Hat OpenStack Platform 17.1.3 or later Supports Red Hat Ceph Storage when externally deployed. Red Hat Satellite 6.x Only registering with the Content Delivery Network (CDN) is supported. Registering with Red Hat Network (RHN) is deprecated and not supported. Client Connector Version Notes S3A 2.8.x, 3.2.x, and trunk Red Hat Ceph Storage as a backup target Version Notes CommVault Cloud Data Management v11 IBM Spectrum Protect Plus 10.1.5 IBM Spectrum Protect server 8.1.8 NetApp AltaVault 4.3.2 and 4.4 Rubrik Cloud Data Management (CDM) 3.2 onwards Trilio, TrilioVault 3.0 S3 target Veeam (object storage) Veeam Availability Suite 9.5 Update 4 Supported on Red Hat Ceph Storage object storage with the S3 protocol Veritas NetBackup for Symantec OpenStorage (OST) cloud backup 7.7 and 8.0 Independent Software vendors Version Notes IBM Spectrum Discover 2.0.3 WekaIO 3.12.2

Commands:
Chapter 18. User Account Service Red Hat Single Sign-On has a built-in User Account Service which every user has access to. This service allows users to manage their account, change their credentials, update their profile, and view their login sessions. The URL to this service is <server-root>/auth/realms/{realm-name}/account . Account Service The initial page is the user's profile, which is the Account left menu item. This is where they specify basic data about themselves. This screen can be extended to allow the user to manage additional attributes. See the Server Developer Guide for more details. The Password left menu item allows the user to change their password. Password Update The Authenticator menu item allows the user to set up OTP if they desire. This will only show up if OTP is a valid authentication mechanism for your realm. Users are given directions to install FreeOTP or Google Authenticator on their mobile device to be their OTP generator. The QR code you see in the screen shot can be scanned into the FreeOTP or Google Authenticator mobile application for nice and easy setup. OTP Authenticator The Federated Identity menu item allows the user to link their account with an identity broker (this is usually used to link social provider accounts together). This will show the list of external identity providers you have configured for your realm. Federated Identity The Sessions menu item allows the user to view and manage which devices are logged in and from where. They can perform logout of these sessions from this screen too. Sessions The Applications menu item shows users which applications they have access to. Applications 18.1. Themeable Like all UIs in Red Hat Single Sign-On, the User Account Service is completely themeable and internationalizable. See the Server Developer Guide for more details.

Commands:
14.8.4. net net <protocol> <function> <misc_options> <target_options> The net utility is similar to the net utility used for Windows and MS-DOS. The first argument is used to specify the protocol to use when executing a command. The <protocol> option can be ads , rap , or rpc for specifying the type of server connection. Active Directory uses ads , Win9x/NT3 uses rap , and Windows NT4/2000/2003 uses rpc . If the protocol is omitted, net automatically tries to determine it. The following example displays a list the available shares for a host named wakko : The following example displays a list of Samba users for a host named wakko :

Commands:
~]# net -l share -S wakko Password: Enumerating shared resources (exports) on remote server: Share name Type Description ---------- ---- ----------- data Disk Wakko data share tmp Disk Wakko tmp share IPCUSD IPC IPC Service (Samba Server) ADMINUSD IPC IPC Service (Samba Server)
~]# net -l user -S wakko root password: User name Comment ----------------------------- andriusb Documentation joe Marketing lisa Sales
10.2. Replicated Volumes vs Geo-replication The following table lists the differences between replicated volumes and geo-replication: Replicated Volumes Geo-replication Works between all bricks in a replica set, so that changes are synced in both directions. Works only from the primary (master) volume to the secondary (slave) volume. Mirrors data across bricks within one trusted storage pool. Mirrors data across geographically distributed trusted storage pools. Provides high-availability. Provides data back-up for disaster recovery. Synchronous replication: each and every file operation is applied to all the bricks. Asynchronous replication: checks for changes in files periodically, and syncs them on detecting differences.

Commands:
8.3.7. Moving Back Toward Normalcy Eventually, all disasters end. The disaster recovery plan must address this phase as well. The new data center must be outfitted with all the necessary hardware and software; while this phase often does not have the time-critical nature of the preparations made when the disaster was initially declared, backup sites cost money every day they are in use, so economic concerns dictate that the switchover take place as quickly as possible. The last backups from the backup site must be made and delivered to the new data center. After they are restored onto the new hardware, production can be switched over to the new data center. At this point the backup data center can be decommissioned, with the disposition of all temporary hardware dictated by the final section of the plan. Finally, a review of the plan's effectiveness is held, with any changes recommended by the reviewing committee integrated into an updated version of the plan.

Commands:
Preface Red Hat Enterprise Linux minor releases are an aggregation of individual enhancement, security, and bug fix errata. The Red Hat Enterprise Linux 6.8 Technical Notes document provides a list of notable bug fixes, all currently available Technology Previews, deprecated functionality, and other information. The Release Notes document describes the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release, as well as known problems. Capabilities and limits of Red Hat Enterprise Linux 6 as compared to other versions of the system are available in the Red Hat Knowledgebase article available at https://access.redhat.com/articles/rhel-limits . For information regarding the Red Hat Enterprise Linux life cycle, refer to https://access.redhat.com/support/policy/updates/errata/ .

Commands:
Chapter 1. Red Hat Ansible Automation Platform 2.3 upgrades Upgrade to Red Hat Ansible Automation Platform 2.3 by setting up your inventory and running the installation script. Ansible then upgrades your deployment to 2.3. If you plan to upgrade from Ansible Automation Platform 2.0 or earlier, you must migrate Ansible content for compatibility with 2.3. 1.1. Ansible Automation Platform upgrades Upgrading to version 2.3 from Ansible Automation Platform 2.1 or later involves downloading the installation package and then performing the following steps: Set up your inventory to match your installation environment. Run the 2.3 installation program over your current Ansible Automation Platform installation. Additional resources Upgrading to Red Hat Ansible Automation Platform 2.3 1.2. Ansible Automation Platform legacy upgrades Upgrading to version 2.3 from Ansible Automation Platform 2.0 or earlier requires you to migrate Ansible content for compatibility. The following steps provide an overview of the legacy upgrade process: Duplicate your custom virtual environments into automation execution environments using the awx-manage command. Migrate data from isolated legacy nodes to execution nodes by performing a side-by-side upgrade so nodes are compatible with the latest automation mesh features. Import or generate a new automation hub API token. Reconfigure your Ansible content to include Fully Qualified Collection Names (FQCN) for compatibility with ansible-core 2.13. Additional resources Migrate virtual environments to automation execution environments Migrate isolated nodes to execution nodes Migrate Ansible content

Commands:
Chapter 7. System and Subscription Management reposync now by default skips packages whose location falls outside the destination directory Previously, the reposync command did not sanitize paths to packages specified in a remote repository, which was insecure. A security fix for CVE-2018-10897 has changed the default behavior of reposync to not store any packages outside the specified destination directory. To restore the original insecure behavior, use the new --allow-path-traversal option. (BZ#1609302)

Commands:
19.7. Enabling a Password Change Dialog There may be situations when a user exists in Identity Management but does not have a valid Kerberos ticket, meaning he cannot authenticate to the IdM domain. This is possible for new users or for users whose domain passwords have expired. Much like enabling password authentication in the web UI, it is possible to enable password-based authentication to the client. This opens up a password change dialog box to allow the user to reset the expired password. The password change dialog is enabled by using OpenSSH's challenge-response authentication. The challenge-response dialog is optional. In many environments, it is not necessary because SSSD can handle changing expired passwords by invoking the required PAM modules. However, using the challenge-response option in OpenSSH makes it possible to do password changes directly in PAM and to support full PAM conversations. This is not enabled by default, but it can be enabled by editing the OpenSSH configuration. Open the /etc/ssh/sshd_config file. Set ChallengeResponseAuthentication to yes .

Commands:
Chapter 2. Accessing the Red Hat Discovery user interface You access the Red Hat Discovery graphical user interface through a browser. Learn more To learn more about the requirements and steps to log in to and out of the Discovery graphical user interface, see the following information: Logging in to the Discovery user interface Logging out of the Discovery user interface 2.1. Logging in to the Discovery user interface To log in to the Discovery user interface, you need the IP address of the system where the Discovery server is installed, the port number for the connection if the default port was changed during server installation, and the server administrator username and password to use when logging in. If you do not have this information, contact the administrator who installed the Discovery server. Prerequisites To use the Discovery graphical user interface, the system on which you want to run the user interface must be able to communicate with the system on which the Discovery server is installed. Procedure In a browser, enter the URL for the Discovery server in the following format: https:// IPaddress : server_port , where IPaddress is the IP address of the Discovery server and server_port is the exposed server port. The following examples show two different ways to enter the URL, based on the system that you are logging in from and whether the default port is used: If you log in from the system where the server is installed and the default port 9443 is used, you can use the loopback address (also known as localhost) as the IP address, as shown in the following example: If you log in from a system that is remote from the server, the server is running on the IP address 192.0.2.0 , and the default port was changed during installation to 8443 , you would log in as shown in the following example: After you enter the URL for the server, the Discovery login page displays. On the login page, enter the username and password for the Discovery server administrator account and then click Log in to log in to the server. Verification steps If this is the first time that you have logged in to Discovery, the Welcome page displays. You can begin by adding sources and credentials that can be used in scans. If you have previously logged in to Discovery, the Welcome page is skipped and you can interact with your previously created sources, credentials, and scans. 2.2. Logging out of the Discovery user interface Procedure In the application toolbar, click the person icon or your username. Click Logout .

Commands:
https://127.0.0.1:9443
https://192.0.2.0:8443
Chapter 1. Overview of AMQ Streams Red Hat AMQ Streams is a massively-scalable, distributed, and high-performance data streaming platform based on the Apache ZooKeeper and Apache Kafka projects. The main components comprise: Kafka Broker Messaging broker responsible for delivering records from producing clients to consuming clients. Apache ZooKeeper is a core dependency for Kafka, providing a cluster coordination service for highly reliable distributed coordination. Kafka Streams API API for writing stream processor applications. Producer and Consumer APIs Java-based APIs for producing and consuming messages to and from Kafka brokers. Kafka Bridge AMQ Streams Kafka Bridge provides a RESTful interface that allows HTTP-based clients to interact with a Kafka cluster. Kafka Connect A toolkit for streaming data between Kafka brokers and other systems using Connector plugins. Kafka MirrorMaker Replicates data between two Kafka clusters, within or across data centers. Kafka Exporter An exporter used in the extraction of Kafka metrics data for monitoring. A cluster of Kafka brokers is the hub connecting all these components. The broker uses Apache ZooKeeper for storing configuration data and for cluster coordination. Before running Apache Kafka, an Apache ZooKeeper cluster has to be ready. Figure 1.1. AMQ Streams architecture 1.1. Using the Kafka Bridge to connect with a Kafka cluster You can use the AMQ Streams Kafka Bridge API to create and manage consumers and send and receive records over HTTP rather than the native Kafka protocol. When you set up the Kafka Bridge you configure HTTP access to the Kafka cluster. You can then use the Kafka Bridge to produce and consume messages from the cluster, as well as performing other operations through its REST interface. Additional resources For information on installing and using the Kafka Bridge, see Using the AMQ Streams Kafka Bridge . 1.2. Document conventions User-replaced values User-replaced values, also known as replaceables , are shown in italics with angle brackets (< >). Underscores ( _ ) are used for multi-word values. If the value refers to code or commands, monospace is also used. For example, in the following code, you will want to replace <bootstrap_address> and <topic_name> with your own address and topic name: bin/kafka-console-consumer.sh --bootstrap-server <bootstrap_address> --topic <topic_name> --from-beginning

Commands:
bin/kafka-console-consumer.sh --bootstrap-server <bootstrap_address> --topic <topic_name> --from-beginning
Chapter 2. Installation This chapter guides you through the steps to install AMQ Core Protocol JMS in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To build programs with AMQ Core Protocol JMS, you must install Apache Maven . To use AMQ Core Protocol JMS, you must install Java. 2.2. Using the Red Hat Maven repository Configure your Maven environment to download the client library from the Red Hat Maven repository. Procedure Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, "Using the online repository" . <repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository> Add the library dependency to your POM file. <dependency> <groupId>org.apache.activemq</groupId> <artifactId>artemis-jms-client</artifactId> <version>2.28.0.redhat-00011</version> </dependency> The client is now available in your Maven project. 2.3. Installing a local Maven repository As an alternative to the online repository, AMQ Core Protocol JMS can be installed to your local filesystem as a file-based Maven repository. Procedure Use your subscription to download the AMQ Broker 7.11.4 Maven repository .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-broker-7.11.4-maven-repository.zip On Windows, right-click the .zip file and select Extract All . Configure Maven to use the repository in the maven-repository directory inside the extracted install directory. For more information, see Section B.2, "Using a local repository" . 2.4. Installing the examples Procedure Use your subscription to download the AMQ Broker 7.11.4 .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-broker-7.11.4.zip On Windows, right-click the .zip file and select Extract All . When you extract the contents of the .zip file, a directory named amq-broker-7.11.4 is created. This is the top-level directory of the installation and is referred to as <install-dir> throughout this document.

Commands:
<repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository>
<dependency> <groupId>org.apache.activemq</groupId> <artifactId>artemis-jms-client</artifactId> <version>2.28.0.redhat-00011</version> </dependency>
unzip amq-broker-7.11.4-maven-repository.zip
unzip amq-broker-7.11.4.zip
Chapter 3. Changing the Directory Manager password The Directory Manager is the privileged database administrator, comparable to the root user in a Linux operating system. The Directory Manager entry and the corresponding password are set during the instance installation. As an administrator, you can change the Directory Manager password to use a different one. 3.1. Changing the Directory Manager password using the command line You can set a new password for the Directory Manager using the dsconf command line utility or manually by setting the nsslapd-rootpw parameter. Important Set the password using an encrypted connection only. Using an unencrypted connection can expose the password to the network. If your server does not support encrypted connections, use the web console to update the Directory Manager password. Procedure Set the Directory Manager password using one of the following options: To encrypt the password automatically: # dsconf -D " cn=Directory Manager " ldaps://server.example.com config replace nsslapd-rootpw= password Directory Server automatically encrypts the plain text value that you set in the nsslapd-rootpw parameter. Warning Do not use curly braces {} in the password. Directory Server stores the password in the {password-storage-scheme}hashed_password format. The server interprets characters in curly braces as the password storage scheme. If the string is an invalid storage scheme or if the password is not correctly hashed, the Directory Manager cannot connect to the server. To encrypt the password manually: Generate a new password hash. For example: # pwdhash -D /etc/dirsrv/slapd- instance_name password {PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty... The password is encrypted using the password storage scheme set in the nsslapd-rootpwstoragescheme attribute of the Directory Server instance configuration. Using a STARTTLS connection, set the nsslapd-rootpw attribute to the value displayed in the step: # dsconf -D " cn=Directory Manager " ldaps://server.example.com config replace nsslapd-rootpw=" {PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty... " Additional resources Changing the Directory Manager password using the web console 3.2. Changing the Directory Manager password using the web console You can set a new password for the Directory Manager using the web console. Prerequisites You are logged in to the instance in the web console. Procedure Open the Server Server Settings Directory Manager menu. Enter the new password into the Directory Manager Password and Confirm Password fields. Optional: Set a different password storage scheme. Click Save .

Commands:
dsconf -D " cn=Directory Manager " ldaps://server.example.com config replace nsslapd-rootpw= password
pwdhash -D /etc/dirsrv/slapd- instance_name password {PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty
dsconf -D " cn=Directory Manager " ldaps://server.example.com config replace nsslapd-rootpw=" {PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty... "