mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Checking IdM replication using Healthcheck You can test Identity Management (IdM) replication using the Healthcheck tool. Prerequisites You are using RHEL version 8.1 or newer. 5.1. Replication healthcheck tests The Healthcheck tool tests the Identity Management (IdM) topology configuration and searches for replication conflict issues. To list all tests, run the ipa-healthcheck with the --list-sources option: The topology tests are placed under the ipahealthcheck.ipa.topology and ipahealthcheck.ds.replication sources: IPATopologyDomainCheck This test verifies: That no single server is disconnected from the topology. That servers do not have more than the recommended number of replication agreements. If the test succeeds, the test returns the configured domains. Otherwise, specific connection errors are reported. Note The test runs the ipa topologysuffix-verify command for the domain suffix. It also runs the command for the ca suffix if the IdM Certificate Authority server role is configured on this server. ReplicationConflictCheck The test searches for entries in LDAP matching (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)) . Note Run these tests on all IdM servers when trying to check for issues. Additional resources Solving common replication problems 5.2. Screening replication using Healthcheck Follow this procedure to run a standalone manual test of an Identity Management (IdM) replication topology and configuration using the Healthcheck tool. The Healthcheck tool includes many tests. Therefore, you can shorten the results with: Replication conflict test: --source=ipahealthcheck.ds.replication Correct topology test: --source=ipahealthcheck.ipa.topology Prerequisites You are logged in as the root user. Procedure To run Healthcheck replication conflict and topology checks, enter: Four different results are possible: SUCCESS - the test passed successfully. WARNING - the test passed but there might be a problem. ERROR - the test failed. CRITICAL - the test failed and it affects the IdM server functionality. Additional resources man ipa-healthcheck 5.3. Additional resources Healthcheck in IdM

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology
{ "source": "ipahealthcheck.ipa.topology", "check": "IPATopologyDomainCheck", "result": "SUCCESS", "kw": { "suffix": "domain" } }
{ "source": "ipahealthcheck.ipa.topology", "check": "IPATopologyDomainCheck", "result": "ERROR", "uuid": d6ce3332-92da-423d-9818-e79f49ed321f "when": 20191007115449Z "duration": 0.005943 "kw": { "msg": "topologysuffix-verify domain failed, server2 is not connected (server2_139664377356472 in MainThread)" } }
8.4. PackageKit 8.4.1. RHBA-2014:1481 - PackageKit bug fix update Updated PackageKit packages that fix several bugs are now available for Red Hat Enterprise Linux 6. PackageKit is a D-Bus abstraction layer that allows the session user to manage packages in a secure way using a cross-distribution, cross-architecture API. Bug Fixes BZ# 743399 Due to a regression, some systems reported the following entry in the Automatic Bug Reporting Tool (ABRT) even though no applications were being tested at the time and the systems were idle: "Process /usr/sbin/packagekitd was killed by signal 11 (SIGSEGV)" A patch has been provided to fix this bug, and ABRT no longer produces such error messages. BZ# 811097 When running the "pkcon install" command, the pkcon utility failed to provide a prompt for the user requiring more information. Instead, the pkcon utility terminated unexpectedly and returned the following error: "Fatal error: user declined simulation" An upstream patch has been provided to fix this bug. As a result, pkcon prompts the user with "Proceed with changes? [N/y]" to get an input, and completes successfully. BZ# 874270 Due to a series of processes all aborting and nsswitch malfunctioning, starting the KVM host or guest displayed error messages on ABRT. The bug has been fixed, and KVM no longer returns error messages. Users of PackageKit are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 2. Accessing the web console The Red Hat OpenShift Service on AWS web console is a user interface accessible from a web browser. Developers can use the web console to visualize, browse, and manage the contents of projects. 2.1. Prerequisites JavaScript must be enabled to use the web console. For the best experience, use a web browser that supports WebSockets . Review the OpenShift Container Platform 4.x Tested Integrations page before you create the supporting infrastructure for your cluster. 2.2. Understanding and accessing the web console The web console runs as a pod on the control plane node. The static assets required to run the web console are served by the pod. Procedure Log in to OpenShift Cluster Manager and click the name of your cluster. On the cluster Overview tab, click Open console , and log in with your credentials. Alternatively, use the oc whoami --show-console command to get the web console URL.

Commands:
Chapter 4. Removed functionality This chapter lists functionalities that were supported in Red Hat OpenShift Data Foundation but are no longer available in OpenShift Data Foundation 4.18. 4.1. MDSCacheUsageHigh alert MDSCacheUsageHigh alert has been removed. This alert was querying rss to send high MDS cache usage warning. However, rss is not the right metrics for this. mds_co_bytes is the correct metric but Ceph does not expose the metric. As a result, wrong alerts were being triggered. The alert has been removed until a better solution is identified.

Commands:
10.3. Disabling and Re-enabling Host Entries Active hosts can be accessed by other services, hosts, and users within the domain. There can be situations when it is necessary to remove a host from activity. However, deleting a host removes the entry and all the associated configuration, and it removes it permanently. 10.3.1. Disabling Host Entries Disabling a host prevents domain users from access it without permanently removing it from the domain. This can be done by using the host-disable command. For example: Important Disabling a host entry not only disables that host. It disables every configured service on that host as well. 10.3.2. Re-enabling Hosts Disabling a host essentially kills its current, active keytabs. Removing the keytabs effectively removes the host from the IdM domain without otherwise touching its configuration entry. To re-enable a host, simply use the ipa-getkeytab command. The -s option sets which IdM server to request the keytab, -p gives the principal name, and -k gives the file to which to save the keytab. For example, requesting a new host keytab: If the ipa-getkeytab command is run on an active IdM client or server, then it can be run without any LDAP credentials ( -D and -w ). The IdM user uses Kerberos credentials to authenticate to the domain. To run the command directly on the disabled host, then supply LDAP credentials to authenticate to the IdM server. The credentials should correspond to the host or service which is being re-enabled.

Commands:
[jsmith@ipaserver ~]USD kinit admin [jsmith@ipaserver ~]USD ipa host-disable server.example.com
[jsmith@ipaserver ~]USD ipa-getkeytab -s ipaserver.example.com -p host/server.example.com -k /etc/krb5.keytab -D fqdn=server.example.com,cn=computers,cn=accounts,dc=example,dc=com -w password
Chapter 11. Configuring manual node reboot to define KernelArgs Overcloud nodes are automatically rebooted when the overcloud deployment includes setting the KernelArgs for the first time. Rebooting nodes can be an issue for existing workloads if you are adding KernelArgs to a deployment that is already in production. You can disable the automatic rebooting of nodes when updating a deployment, and instead perform node reboots manually after each overcloud deployment. Note If you disable automatic reboot and then add new Compute nodes to your deployment, the new nodes will not be rebooted during their initial provisioning. This might cause deployment errors because the configuration of KernelArgs is applied only after a reboot. 11.1. Configuring manual node reboot to define KernelArgs You can disable the automatic rebooting of nodes when you configure KernelArgs for the first time, and instead reboot the nodes manually. Procedure Log in to the undercloud as the stack user. Source the stackrc file: Enable the KernelArgsDeferReboot role parameter in a custom environment file, for example, kernelargs_manual_reboot.yaml : Add your custom environment file to the stack with your other environment files and deploy the overcloud: Retrieve a list of your Compute nodes to identify the host name of the node that you want to reboot: Disable the Compute service on the Compute node you want to reboot, to prevent the Compute scheduler from assigning new instances to the node: Replace <node> with the host name of the node you want to disable the Compute service on. Retrieve a list of the instances hosted on the Compute node that you want to migrate: Migrate the instances to another Compute node. For information on migrating instances, see Migrating virtual machine instances between Compute nodes . Log in to the node that you want to reboot. Reboot the node: Wait until the node boots. Re-enable the Compute node: Check that the Compute node is enabled:

Commands:
[stack@director ~]USD source ~/stackrc
parameter_defaults: <Role>Parameters: KernelArgsDeferReboot: True
(undercloud)USD openstack overcloud deploy --templates -e [your environment files] -e /home/stack/templates/kernelargs_manual_reboot.yaml
(undercloud)USD source ~/overcloudrc (overcloud)USD openstack compute service list
(overcloud)USD openstack compute service set <node> nova-compute --disable
(overcloud)USD openstack server list --host <node_UUID> --all-projects
[heat-admin@overcloud-compute-0 ~]USD sudo reboot
(overcloud)USD openstack compute service set <node_UUID> nova-compute --enable
(overcloud)USD openstack compute service list
Chapter 1. All-in-one Red Hat OpenStack Platform installation The all-in-one installation method uses TripleO to deploy Red Hat OpenStack Platform and related services with a simple, single-node environment. Use this installation to enable proof-of-concept, development, and test deployments on a single node with limited or no follow-up operations. Note This feature is available in this release as a Technology Preview , and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details . 1.1. Prerequisites Your system must have a Red Hat Enterprise Linux 8.4 base operating system installed. Your system must have two network interfaces so that internet connectivity is not disrupted while TripleO configures the second interface. Your system must have 4 CPUs, 8GB RAM, and 30GB disk space. Example network configuration Interface eth0 assigned to the default network 192.168.122.0/24. Use this interface for general connectivity. This interface must have internet access. Interface eth1 assigned to the management network 192.168.25.0/24. TripleO uses this interface for the OpenStack services.

Commands:
Chapter 8. Configuring event notification You can use the Red Hat Hybrid Cloud Console settings to configure notifications for events that happen in the edge management. At the moment, the following notifications are configurable: Image Creation Update Devices Prerequisites You have administrator access to the Red Hat Hybrid Cloud Console web user interface. You have an account on Red Hat Customer Portal with an Insights subscription. Procedure To configure the notifications, you must: Create a behavior group. Select the Send an email action. Choose the recipients of that event notification. Associate it to the event type or types that you want. With that, every time a device is updated or a new image is created, the group of recipients will be notified in an email about the changes. To learn how to set email notifications, see Configuring notifications for recommendations .

Commands:
9.2. USB Devices This section gives the commands required for handling USB devices. 9.2.1. Assigning USB Devices to Guest Virtual Machines Most devices such as web cameras, card readers, keyboards, or mice are connected to a computer using a USB port and cable. There are two ways to pass such devices to a guest virtual machine: Using USB passthrough - this requires the device to be physically connected to the host physical machine that is hosting the guest virtual machine. SPICE is not needed in this case. USB devices on the host can be passed to the guest using the command line or virt-manager . Refer to Section 15.3.1, "Attaching USB Devices to a Guest Virtual Machine" for virt manager directions. Note virt-manager should not be used for hot plugging or hot unplugging devices. If you want to hot plug/or hot unplug a USB device, refer to Procedure 14.1, "Hot plugging USB devices for use by the guest virtual machine" . Using USB re-direction - USB re-direction is best used in cases where there is a host physical machine that is running in a data center. The user connects to his/her guest virtual machine from a local machine or thin client. On this local machine there is a SPICE client. The user can attach any USB device to the thin client and the SPICE client will redirect the device to the host physical machine on the data center so it can be used by the guest virtual machine that is running on the thin client. For instructions on USB re-direction using the virt-manager , refer to Section 15.3.1, "Attaching USB Devices to a Guest Virtual Machine" It should be noted that USB redirection is not possible using the TCP protocol (Refer to BZ#1085318 ).

Commands:
Virtualization Security Guide Red Hat Enterprise Linux 6 Securing your virtual environment Jiri Herrmann Red Hat Customer Content Services jherrman@redhat.com Yehuda Zimmerman Red Hat Customer Content Services yzimmerm@redhat.com Scott Radvan Red Hat Customer Content Services Tahlia Richardson Red Hat Customer Content Services Thanks go to the following people for enabling the creation of this guide: Paul Moore Red Hat Engineering Kurt Seifried Red Hat Engineering David Jorm Red Hat Engineering

Commands:
24.2.3. 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 23.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:
Chapter 4. Technology previews This section describes the technology preview features introduced in Red Hat OpenShift Data Foundation 4.16 under Technology Preview support limitations. Important Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. Technology Preview features are provided with a limited support scope, as detailed on the Customer Portal: Technology Preview Features Support Scope . 4.1. Deploying OpenShift Data Foundation with Red Hat OpenShift Service on AWS with hosted control planes OpenShift Data Foundation is now available for deployment with Red Hat OpenShift Service on AWS (ROSA) hosted control planes (HCP) as a technology preview. For more information, see Deploying OpenShift Data Foundation using Red Hat OpenShift Service on AWS with hosted control planes . 4.2. Azure Key Vault option for cluster wide/PV encryption OpenShift Data Foundation supports Azure Key Vault for cluster-wide PV encryption on Microsoft Azure platform. This helps to use a local native solution for Azure instead of a third party tool. For more information, see Creating an OpenShift Data Foundation cluster . 4.3. Bucket logging and log based replication optimization for Multicloud Object Gateway buckets Supports replication of large amounts of data between Multicloud Object Gateway (MCG) and Amazon Web Services (AWS) or MCG and MCG. The support for log-based replication for AWS S3 using bucket logging is extended to MCG bucket for optimization. The log-based replication optimization also supports object prefix filtering. For more information, see Enabling bucket logging for Multicloud Object Gateway . 4.4. Multi network plug-in (Multus) support for IPv6 Multus networks can be configured to use either IPv4 or IPv6. OpenShift Data Foundation supports Multus networks that are pure IPv4 or pure IPv6. Networks cannot be in a mixed mode. For more information on Mutlus, see Multi network plug-in (Multus) support .

Commands:
Chapter 2. Installing the JBoss Web Server collection As a first step toward automating deployments of Red Hat JBoss Web Server by using Ansible, you must download and install the JBoss Web Server collection from Ansible automation hub . The JBoss Web Server collection is named redhat.jws in Ansible automation hub . Before you install the JBoss Web Server collection, you must ensure that your system complies with certain prerequisites. Prerequisites You have installed the ansible-core package version 2.16 or later on a control node in your system by installing Red Hat Ansible Automation Platform 2. x . For more information about installing Red Hat Ansible Automation Platform, see the Red Hat Ansible Automation Platform Installation Guide . You have updated the ansible.cfg file to use Ansible automation hub as your primary source of Ansible collections. For more information about updating the ansible.cfg file, see Getting started with automation hub . Procedure On your Ansible control node, enter the following command: Note If the preceding command produces a Failed to find collection redhat.jws:* error message, ensure that you have updated the ansible.cfg file correctly to use Ansible automation hub, as described in Getting started with automation hub . The preceding command produces the following output: For the sake of brevity, the preceding example uses ellipses to denote omitted text. In the preceding output, <version> represents the latest available versions of the installed redhat.jws , redhat.runtimes_common , and ansible.posix collections. Verification On your Ansible control node, enter the following command: The preceding command displays the list of installed collections. For example: As shown in the preceding example, when you install the redhat.jws collection, the latest versions of the ansible.posix and redhat.runtimes_common collections are also automatically downloaded and installed on your Ansible control node. The redhat.runtimes_common collection provides a set of standard utilities to support the automated deployment of various Red Hat Runtimes products such as JBoss Web Server. Note If the latest versions of the ansible.posix and redhat.runtimes_common collections already exist on your Ansible control node, these collections are not automatically installed again. Additional resources Automation Hub: Connect to Hub

Commands:
ansible-galaxy collection install redhat.jws
Starting galaxy collection install process Process install dependency map Starting collection install process redhat.jws: <version> was installed successfully redhat.runtimes_common: <version> was installed successfully ansible.posix: <version> was installed successfully
ansible-galaxy collection list
Collection Version -------------------------- ------- ansible.posix <version> redhat.jws <version> redhat.runtimes_common <version>
Chapter 12. Using Metering on AMQ Streams You can use the Metering tool that is available on OpenShift to generate metering reports from different data sources. As a cluster administrator, you can use metering to analyze what is happening in your cluster. You can either write your own, or use predefined SQL queries to define how you want to process data from the different data sources you have available. Using Prometheus as a default data source, you can generate reports on pods, namespaces, and most other Kubernetes resources. You can also use the OpenShift Metering operator to analyze your installed AMQ Streams components to determine whether you are in compliance with your Red Hat subscription. To use metering with AMQ Streams, you must first install and configure the Metering operator on OpenShift Container Platform. 12.1. Metering resources Metering has many resources which can be used to manage the deployment and installation of metering, as well as the reporting functionality metering provides. Metering is managed using the following CRDs: Table 12.1. Metering resources Name Description MeteringConfig Configures the metering stack for deployment. Contains customizations and configuration options to control each component that makes up the metering stack. Reports Controls what query to use, when, and how often the query should be run, and where to store the results. ReportQueries Contains the SQL queries used to perform analysis on the data contained within ReportDataSources . ReportDataSources Controls the data available to ReportQueries and Reports. Allows configuring access to different databases for use within metering. 12.2. Metering labels for AMQ Streams The following table lists the metering labels for AMQ Streams infrastructure components and integrations. Table 12.2. Metering Labels Label Possible values com.company Red_Hat rht.prod_name Red_Hat_Integration rht.prod_ver 2022.Q2 rht.comp AMQ_Streams rht.comp_ver 2.1 rht.subcomp Infrastructure cluster-operator entity-operator zookeeper Application kafka-broker kafka-connect kafka-connect-build kafka-mirror-maker2 kafka-mirror-maker cruise-control kafka-bridge kafka-exporter drain-cleaner rht.subcomp_t infrastructure application Examples Infrastructure example (where the infrastructure component is entity-operator ) com.company=Red_Hat rht.prod_name=Red_Hat_Integration rht.prod_ver=2022.Q2 rht.comp=AMQ_Streams rht.comp_ver=2.1 rht.subcomp=entity-operator rht.comp_t=infrastructure Application example (where the integration deployment name is kafka-bridge ) com.company=Red_Hat rht.prod_name=Red_Hat_Integration rht.prod_ver=2022.Q2 rht.comp=AMQ_Streams rht.comp_ver=2.1 rht.subcomp=kafka-bridge rht.comp_t=application

Commands:
com.company=Red_Hat rht.prod_name=Red_Hat_Integration rht.prod_ver=2022.Q2 rht.comp=AMQ_Streams rht.comp_ver=2.1 rht.subcomp=entity-operator rht.comp_t=infrastructure
com.company=Red_Hat rht.prod_name=Red_Hat_Integration rht.prod_ver=2022.Q2 rht.comp=AMQ_Streams rht.comp_ver=2.1 rht.subcomp=kafka-bridge rht.comp_t=application
Chapter 34. Customizing the process designer You can customize the process designer in Business Central by editing the properties of the diagram editor on the Business Central Settings page. Procedure In Business Central, select the Admin icon in the top-right corner of the screen and select Process Designer . In the Properties section, update any of the following properties: Select the Auto hide category panel check box to automatically hide a category toolbar panel. In the Drawing area width field, enter an integer value between 2800 and 5600 to set the width of the drawing area. In the Drawing area height field, enter an integer value between 1400 and 2800 to set the height of the drawing area. Select the Enable HiDPI check box if you are using a high resolution display and are seeing blurry text and objects. This option is disabled by default. Click Save .

Commands: