mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. About the multicluster engine for Kubernetes Operator One of the challenges of scaling Kubernetes environments is managing the lifecycle of a growing fleet. To meet that challenge, you can use the multicluster engine Operator. The operator delivers full lifecycle capabilities for managed OpenShift Container Platform clusters and partial lifecycle management for other Kubernetes distributions. It is available in two ways: As a standalone operator that you install as part of your OpenShift Container Platform or OpenShift Kubernetes Engine subscription As part of Red Hat Advanced Cluster Management for Kubernetes 5.1. Cluster management with multicluster engine on OpenShift Container Platform When you enable multicluster engine on OpenShift Container Platform, you gain the following capabilities: Hosted control planes , which is a feature that is based on the HyperShift project. With a centralized hosted control plane, you can operate OpenShift Container Platform clusters in a hyperscale manner. Hive, which provisions self-managed OpenShift Container Platform clusters to the hub and completes the initial configurations for those clusters. klusterlet agent, which registers managed clusters to the hub. Infrastructure Operator, which manages the deployment of the Assisted Service to orchestrate on-premise bare metal and vSphere installations of OpenShift Container Platform, such as SNO on bare metal. The Infrastructure Operator includes GitOps Zero Touch Provisioning (ZTP) , which fully automates cluster creation on bare metal and vSphere provisioning with GitOps workflows to manage deployments and configuration changes. Open cluster management, which provides resources to manage Kubernetes clusters. The multicluster engine is included with your OpenShift Container Platform support subscription and is delivered separately from the core payload. To start to use multicluster engine, you deploy the OpenShift Container Platform cluster and then install the operator. For more information, see Installing and upgrading multicluster engine operator . 5.2. Cluster management with Red Hat Advanced Cluster Management If you need cluster management capabilities beyond what OpenShift Container Platform with multicluster engine can provide, consider Red Hat Advanced Cluster Management. The multicluster engine is an integral part of Red Hat Advanced Cluster Management and is enabled by default. 5.3. Additional resources For the complete documentation for multicluster engine, see Cluster lifecycle with multicluster engine documentation , which is part of the product documentation for Red Hat Advanced Cluster Management.

Commands:
13.8. Locking Down User Logout and User Switching Follow these steps to prevent the user from logging out. Create the /etc/dconf/profile/user profile which contains the following lines: local is the name of a dconf database. Create the directory /etc/dconf/db/local.d/ if it does not already exist. Create the key file /etc/dconf/db/local.d/00-logout to provide information for the local database: Override the user's setting and prevent the user from changing it in /etc/dconf/db/local.d/locks/lockdown : Update the system databases: Users must log out and back in again before the system-wide settings take effect. Important Users can evade the logout lockdown by switching to a different user, which can thwart system administrator's intentions. That is the reason why it is recommended to disable "user switching" as well to prevent this scenario from occurring. Procedure 13.8. Prevent the User form Switching to a Different User Account Create the /etc/dconf/profile/user profile which contains the following lines: local is the name of a dconf database. Create the directory /etc/dconf/db/local.d/ if it does not already exist. Create the key file /etc/dconf/db/local.d/00-user-switching to provide information for the local database: Override the user's setting and prevent the user from changing it in /etc/dconf/db/local.d/locks/lockdown : Update the system databases: Users must log out and back in again before the system-wide settings take effect.

Commands:
user-db:user system-db:local
Prevent the user from user switching disable-log-out=true
Lock this key to disable user logout /org/gnome/desktop/lockdown/disable-log-out
dconf update
user-db:user system-db:local
Prevent the user from user switching disable-user-switching=true
Lock this key to disable user switching /org/gnome/desktop/lockdown/disable-user-switching
dconf update
Chapter 1. Getting started with Red Hat Quay configuration Red Hat Quay can be deployed by an independent, standalone configuration, or by using the OpenShift Container Platform Red Hat Quay Operator. How you create, retrieve, update, and validate the Red Hat Quay configuration varies depending on the type of deployment you are using. However, the core configuration options are the same for either deployment type. Core configuration can be set by one of the following options: Directly, by editing the config.yaml file. See "Editing the configuration file" for more information. Programmatically, by using the configuration API. See "Using the configuration API" for more information. Visually, by using the configuration tool UI. See "Using the configuration tool" for more information. For standalone deployments of Red Hat Quay, you must supply the minimum required configuration parameters before the registry can be started. The minimum requirements to start a Red Hat Quay registry can be found in the "Retrieving the current configuration" section. If you install Red Hat Quay on OpenShift Container Platform using the Red Hat Quay Operator, you do not need to supply configuration parameters because the Red Hat Quay Operator supplies default information to deploy the registry. After you have deployed Red Hat Quay with the desired configuration, you should retrieve, and save, the full configuration from your deployment. The full configuration contains additional generated values that you might need when restarting or upgrading your system.

Commands:
function::ansi_set_color2 Name function::ansi_set_color2 - Set the ansi Select Graphic Rendition mode. Synopsis Arguments fg Foreground color to set. bg Background color to set. General Syntax ansi_set_color2(fg:long, bg:long) Description Sends ansi code for Select Graphic Rendition mode for the given forground color, Black (30), Blue (34), Green (32), Cyan (36), Red (31), Purple (35), Brown (33), Light Gray (37) and the given background color, Black (40), Red (41), Green (42), Yellow (43), Blue (44), Magenta (45), Cyan (46), White (47).

Commands:
function ansi_set_color2(fg:long,bg:long)
12.4. Configuring a Mail Server for Certificate System Notifications The notifications and jobs features use the mail server configured in the Certificate System CA instances to send notification messages. Before you start setting up the mail server, ensure the following parameters are specified in the CS.cfg configuration file: Set up a mail server by doing the following: Open the CA subsystem administrative console. For example: In the Configuration tab, highlight the instance name at the top, and select the SMTP tab. Supply the server name and port number of the mail server. The server name is the fully qualified DNS hostname of the machine on which the mail server is installed, such as mail.example.com . By default, the hostname of the mail server is localhost instead of the actual hostname. The default port number on which the SMTP mail server listens is 25 . Click Save . Note pkiconsole is being deprecated.

Commands:
smtp.host=localhost smtp.port=25
pkiconsole https://server.example.com:8443/ca
Chapter 2. Console monitoring and alerting Red Hat Quay provides support for monitoring instances that were deployed by using the Red Hat Quay Operator, from inside the OpenShift Container Platform console. The new monitoring features include a Grafana dashboard, access to individual metrics, and alerting to notify for frequently restarting Quay pods. Note To enable the monitoring features, you must select All namespaces on the cluster as the installation mode when installing the Red Hat Quay Operator. 2.1. Dashboard On the OpenShift Container Platform console, click Monitoring Dashboards and search for the dashboard of your desired Red Hat Quay registry instance: The dashboard shows various statistics including the following: The number of Organizations , Repositories , Users , and Robot accounts CPU Usage Max memory usage Rates of pulls and pushes, and authentication requests API request rate Latencies 2.2. Metrics You can see the underlying metrics behind the Red Hat Quay dashboard by accessing Monitoring Metrics in the UI. In the Expression field, enter the text quay_ to see the list of metrics available: Select a sample metric, for example, quay_org_rows : This metric shows the number of organizations in the registry. It is also directly surfaced in the dashboard. 2.3. Alerting An alert is raised if the Quay pods restart too often. The alert can be configured by accessing the Alerting rules tab from Monitoring Alerting in the console UI and searching for the Quay-specific alert: Select the QuayPodFrequentlyRestarting rule detail to configure the alert:

Commands:
B.89. sssd B.89.1. RHBA-2010:0971 - sssd bug fix update Updated sssd packages that fix various bugs are now available for Red Hat Enterprise Linux 6. The System Security Services Daemon (SSSD) provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources. It is also the basis to provide client auditing and policy services for projects like FreeIPA. Bug Fixes BZ# 658374 During an upgrade of the sssd package, the package manager restarts the sssd service to ensure the running instance is properly replaced with the newer version. However, prior to this update, a race condition could occur upon the service shutdown, causing the parent process not to wait for its children to terminate. When this happened, these running sub-processes may have prevented sssd from starting again. With this update, the sssd service has been corrected to wait for the children processes to terminate, so that it can be restarted as expected. BZ# 660585 On 32-bit architectures, running the "getent passwd" command on a username with a very large user or group identifier (that is, UID or GID greater than 2147483647) resulted in an empty output. With this update, the underlying source code has been modified to address this issue, and the getent command now returns the expected output. BZ# 660592 Previously, shutting down the sssd service (either by using the "service sssd stop" command, or with the SIGTERM signal) could cause the service to stop responding. This error has been fixed, and sssd no longer fails to shut down. All users of sssd are advised to upgrade to these updated packages, which resolve these issues.

Commands:
C.4.4. Create a Mapping to Allow Access to the Device's Decrypted Contents To access the device's decrypted contents, a mapping must be established using the kernel device-mapper . It is useful to choose a meaningful name for this mapping. LUKS provides a UUID (Universally Unique Identifier) for each device. This, unlike the device name (eg: /dev/sda3 ), is guaranteed to remain constant as long as the LUKS header remains intact. To find a LUKS device's UUID, run the following command: An example of a reliable, informative and unique mapping name would be luks-<uuid> , where <uuid> is replaced with the device's LUKS UUID (eg: luks-50ec957a-5b5a-47ee-85e6-f8085bbc97a8 ). This naming convention might seem unwieldy but is it not necessary to type it often. There should now be a device node, /dev/mapper/<name> , which represents the decrypted device. This block device can be read from and written to like any other unencrypted block device. To see some information about the mapped device, use the following command: Note For more information, read the dmsetup(8) man page.

Commands:
cryptsetup luksUUID <device>
cryptsetup luksOpen <device> <name>
dmsetup info <name>
10.8. Manually Reviewing the Certificate Status Using the Web Interface Open the following URL in a web browser: Authenticate as an agent. For information about authenticating as a user and configuring your browser, see Section 2.4.1, "Browser Initialization" . On the sidebar on the left, click the List requests link. Filter the requests by selecting Show all requests for Request type and Show pending requests for Request status . Click Find in the lower right corner. The results page lists all pending requests waiting for review. Click on the request number to review a request. Review the request information and ensure that it is a legitimate request. If necessary, modify the policy information to correct any mistakes or make any desired changes to the certificate, such as changing the not valid after field. Optionally, leave an additional note. The drop down menu includes several review status updates. Select Approve request to approve the request or Reject request to deny it, and click Submit . Organizations can subscribe semantic differences to Reject request and Cancel Request ; both result in no certificate being issued.

Commands:
https:// server_host_name :8443/ca/agent/ca
3.3. Configuring Fencing for Cluster Members Once you have completed the initial steps of creating a cluster and creating fence devices, you need to configure fencing for the cluster nodes. To configure fencing for the nodes after creating a new cluster and configuring the fencing devices for the cluster, follow the steps in this section. Note that you must configure fencing for each node in the cluster. The following sections provide procedures for configuring a single fence device for a node, configuring a node with a backup fence device, and configuring a node with redundant power supplies: Section 3.3.1, "Configuring a Single Fence Device for a Node" Section 3.3.2, "Configuring a Backup Fence Device" Section 3.3.3, "Configuring a Node with Redundant Power" 3.3.1. Configuring a Single Fence Device for a Node Use the following procedure to configure a node with a single fence device. From the cluster-specific page, you can configure fencing for the nodes in the cluster by clicking on Nodes along the top of the cluster display. This displays the nodes that constitute the cluster. This is also the default page that appears when you click on the cluster name beneath Manage Clusters from the menu on the left side of the luci Homebase page. Click on a node name. Clicking a link for a node causes a page to be displayed for that link showing how that node is configured. The node-specific page displays any services that are currently running on the node, as well as any failover domains of which this node is a member. You can modify an existing failover domain by clicking on its name. On the node-specific page, under Fence Devices , click Add Fence Method . This displays the Add Fence Method to Node dialog box. Enter a Method Name for the fencing method that you are configuring for this node. This is an arbitrary name that will be used by Red Hat High Availability Add-On; it is not the same as the DNS name for the device. Click Submit . This displays the node-specific screen that now displays the method you have just added under Fence Devices . Configure a fence instance for this method by clicking the Add Fence Instance button that appears beneath the fence method. This displays the Add Fence Device (Instance) drop-down menu from which you can select a fence device you have previously configured, as described in Section 3.2.1, "Creating a Fence Device" . Select a fence device for this method. If this fence device requires that you configure node-specific parameters, the display shows the parameters to configure. Note For non-power fence methods (that is, SAN/storage fencing), Unfencing is selected by default on the node-specific parameters display. This ensures that a fenced node's access to storage is not re-enabled until the node has been rebooted. For information on unfencing a node, see the fence_node (8) man page. Click Submit . This returns you to the node-specific screen with the fence method and fence instance displayed.

Commands:
8.8. Receive Flow Steering (RFS) Receive Flow Steering (RFS) extends RPS behavior to increase the CPU cache hit rate and thereby reduce network latency. Where RPS forwards packets based solely on queue length, RFS uses the RPS backend to calculate the most appropriate CPU, then forwards packets based on the location of the application consuming the packet. This increases CPU cache efficiency. RFS is disabled by default. To enable RFS, you must edit two files: /proc/sys/net/core/rps_sock_flow_entries Set the value of this file to the maximum expected number of concurrently active connections. We recommend a value of 32768 for moderate server loads. All values entered are rounded up to the nearest power of 2 in practice. /sys/class/net/ device /queues/ rx-queue /rps_flow_cnt Replace device with the name of the network device you wish to configure (for example, eth0 ), and rx-queue with the receive queue you wish to configure (for example, rx-0 ). Set the value of this file to the value of rps_sock_flow_entries divided by N , where N is the number of receive queues on a device. For example, if rps_flow_entries is set to 32768 and there are 16 configured receive queues, rps_flow_cnt should be set to 2048 . For single-queue devices, the value of rps_flow_cnt is the same as the value of rps_sock_flow_entries . Data received from a single sender is not sent to more than one CPU. If the amount of data received from a single sender is greater than a single CPU can handle, configure a larger frame size to reduce the number of interrupts and therefore the amount of processing work for the CPU. Alternatively, consider NIC offload options or faster CPUs. Consider using numactl or taskset in conjunction with RFS to pin applications to specific cores, sockets, or NUMA nodes. This can help prevent packets from being processed out of order.

Commands:
Chapter 9. Downloading the test plan from Red Hat Certification Portal Procedure Log in to Red Hat Certification portal . Search for the case number related to your product certification, and copy it. Click Cases enter the product case number. Optional: Click Test Plans . The test plan displays a list of components that will be tested during the test run. Click Download Test Plan . If you plan to use CLI to run the tests, see Running certification tests by using CLI and downloading the results file . Otherwise, if you plan to use Cockpit to run the tests, see the Appendix .

Commands:
6.2. RHEA-2015:1354 - new packages: lshw New lshw packages are now available for Red Hat Enterprise Linux 6. The lshw packages include a utility that provides detailed information on the hardware configuration of a machine. It reports, for example, information about memory configuration, firmware version, motherboard configuration, CPU version and speed, cache configuration, and bus speed. All users who require lshw are advised to install these new packages.

Commands:
Appendix B. Using AMQ Broker with the examples The AMQ JavaScript examples require a running message broker with a queue named examples . Use the procedures below to install and start the broker and define the queue. B.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> . B.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 ... B.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --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. B.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 2020-10-08 11:24:01 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 examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
Chapter 6. Internationalization 6.1. Red Hat Enterprise Linux 8 international languages Red Hat Enterprise Linux 8 supports the installation of multiple languages and the changing of languages based on your requirements. East Asian Languages - Japanese, Korean, Simplified Chinese, and Traditional Chinese. European Languages - English, German, Spanish, French, Italian, Portuguese, and Russian. The following table lists the fonts and input methods provided for various major languages. Language Default Font (Font Package) Input Methods English dejavu-sans-fonts French dejavu-sans-fonts German dejavu-sans-fonts Italian dejavu-sans-fonts Russian dejavu-sans-fonts Spanish dejavu-sans-fonts Portuguese dejavu-sans-fonts Simplified Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libpinyin, libpinyin Traditional Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libzhuyin, libzhuyin Japanese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-kkc, libkkc Korean google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-hangul, libhangu 6.2. Notable changes to internationalization in RHEL 8 RHEL 8 introduces the following changes to internationalization compared to RHEL 7: Support for the Unicode 11 computing industry standard has been added. Internationalization is distributed in multiple packages, which allows for smaller footprint installations. For more information, see Using langpacks . The glibc package updates for multiple locales are now synchronized with the Common Locale Data Repository (CLDR).

Commands: