mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 30. Installing and running the IdM Healthcheck tool Learn more about the IdM Healthcheck tool and how to install and run it. Note The Healthcheck tool is only available on RHEL 8.1 or later. 30.1. Healthcheck in IdM The Healthcheck tool in Identity Management (IdM) helps find issues that might impact the health of your IdM environment. Note The Healthcheck tool is a command line tool that can be used without Kerberos authentication. Modules are Independent Healthcheck consists of independent modules which test for: Replication issues Certificate validity Certificate Authority infrastructure issues IdM and Active Directory trust issues Correct file permissions and ownership settings Two output formats Healthcheck generates the following outputs, which you can set using the output-type option: json : Machine-readable output in JSON format (default) human : Human-readable output You can specify a different file destination with the --output-file option. Results Each Healthcheck module returns one of the following results: SUCCESS configured as expected WARNING not an error, but worth keeping an eye on or evaluating ERROR not configured as expected CRITICAL not configured as expected, with a high possibility for impact 30.2. Installing IdM Healthcheck You can install the IdM Healthcheck tool. Procedure Install the ipa-healthcheck package: Note On RHEL 8.1 and 8.2 systems, use the yum install /usr/bin/ipa-healthcheck command instead. Verification Use the --failures-only option to have ipa-healthcheck only report errors. A fully-functioning IdM installation returns an empty result of [] . Additional resources Use ipa-healthcheck --help to see all supported arguments. 30.3. Running IdM Healthcheck Healthcheck can be run manually or automatically using log rotation . Prerequisites The Healthcheck tool must be installed. See Installing IdM Healthcheck . Procedure To run healthcheck manually, enter the ipa-healthcheck command. Additional resources For all options, see the man page: man ipa-healthcheck . 30.4. Additional resources See the following sections of the Configuring and managing Identity Management guide for examples of using IdM Healthcheck. Checking services Verifying your IdM and AD trust configuration Verifying certificates Verifying system certificates Checking disk space Verifying permissions of IdM configuration files Checking replication You can also see those chapters organized into a single guide: Using IdM Healthcheck to monitor your IdM environment

Commands:
yum install ipa-healthcheck
ipa-healthcheck --failures-only []
ipa-healthcheck
4.301. spice-protocol 4.301.1. RHEA-2011:1629 - spice-protocol bug fix and enhancement update An updated spice-protocol package that fixes one bug and adds several enhancements is now available for Red Hat Enterprise Linux 6. The spice-protocol package contains header files that describe the SPICE protocol and the QXL para-virtualized graphics card. The SPICE protocol is needed to build newer versions of the spice-client and the spice-server packages. The spice-protocol package has been upgraded to upstream version 0.8.1, which provides a number of enhancements over the version, including support for asynchronous guest I/O operations, support for suspending guest I/O operations, and support for changing guest volume. (BZ# 723480 ) Bug Fix BZ# 738262 The SPICE client failed to connect to the SPICE server on the target host after a virtual machine had been migrated to a remote machine. This happened when the migration of the virtual machine took longer than the expiration time of the SPICE ticket that was set on the target host. Without a valid password, the SPICE server refused connection from the SPICE client and the SPICE session had to be closed. To prevent this problem, support for spice semi-seamless migration has been added. Other components such as spice-client, spice-server and qemu-kvm have also been modified to support this feature. SPICE now allows the SPICE client to connect to the SPICE server on the target host at the very start of the virtual machine migration, just before the migrate monitor command is given to the qemu-kvm application. With a valid ticket on the target host, the SPICE ticket on the destination no longer expires and the SPICE client now remains open when the virtual machine migration is done. All users of spice-protocol are advised to upgrade to this updated package, which fixes this bug and adds these enhancements.

Commands:
Chapter 3. Installing Red Hat Insights for Red Hat Enterprise Linux (RHEL) This document provides starting points and resources for registering systems to Red Hat Insights for Red Hat Enterprise Linux. Installation of Red Hat Insights typically involves installing the Insights client, then registering systems for use with Insights. You can use different methods to register and install Insights. A registration assistant is also available to guide you through the process of registering and installing Insights. You can also use the Remote Host Configuration (RHC) tool. The installation method you use can depend on conditions such as, Whether you are connecting to Red Hat for the first time Whether you use a certain version of RHEL Whether you want to do an automated installation or manual install Other factors 3.1. Installing Red Hat Insights using the Registration Assistant as an interactive guide You can use the Registration Assistant as a starting point to help you start using Red Hat Insights. The Registration Assistant provides an interactive guide to help you register and install Insights. To start the Registration Assistant, click or go to: Red Hat Hybrid Cloud Console > Red Hat Enterprise Linux > Red Hat Insights > Register Systems 3.2. Installing Red Hat Insights using the Client Configuration Guide You can also get started with Insights by following steps in the product documentation for configuring the Insights client. To install Red Hat Insights, use the: Client Configuration Guide for Red Hat Insights 3.3. Installing Red Hat Insights on Red Hat Enterprise Linux Satellite-managed hosts To install Insights on Red Hat Enterprise Linux hosts managed by Red Hat Satellite, see: Creating a Host in Red Hat Satellite Using Ansible roles to automate repetitive tasks on clients Monitoring Hosts Using Red Hat Insights Red Hat Satellite: How to obtain Insights Advisor recommendations 3.4. Installing Red Hat Insights on existing RHEL systems managed by Red Hat Subscription Management (RHSM), Red Hat Satellite, or Cloud Access To install Insights on existing RHEL systems managed by Red Hat Subscription Management, Satellite or Cloud access, see: Deploying Red Hat Insights on existing RHEL systems managed by Red Hat Cloud Access Red Hat Subscription Management 3.5. Installing Red Hat Insights on existing RHEL systems purchased from a marketplace and managed by Red Hat To install Insights on existing RHEL systems purchased from a marketplace and managed by Red Hat, see: Deploying Red Hat Insights on existing RHEL systems managed by Red Hat Cloud Access 3.6. Installing Red Hat Insights on existing RHEL systems purchased from a marketplace, not directly managed by Red Hat To install Insights on existing RHEL systems purchased from a marketplace, not directly managed by Red Hat, see: Deploying Red Hat Insights on existing RHEL systems managed by Red Hat Update Infrastructure Additional Resources Setup and use Cloud Connector to integrate Insights with Satellite 6.7

Commands:
22.2. Enabling and Disabling Write Barriers To mitigate the risk of data corruption during power loss, some storage devices use battery-backed write caches. Generally, high-end arrays and some hardware controllers use battery-backed write caches. However, because the cache's volatility is not visible to the kernel, Red Hat Enterprise Linux 7 enables write barriers by default on all supported journaling file systems. Note Write caches are designed to increase I/O performance. However, enabling write barriers means constantly flushing these caches, which can significantly reduce performance. For devices with non-volatile, battery-backed write caches and those with write-caching disabled, you can safely disable write barriers at mount time using the -o nobarrier option for mount . However, some devices do not support write barriers; such devices log an error message to /var/log/messages . For more information, see Table 22.1, "Write Barrier Error Messages per File System" . Table 22.1. Write Barrier Error Messages per File System File System Error Message ext3/ext4 JBD: barrier-based sync failed on device - disabling barriers XFS Filesystem device - Disabling barriers, trial barrier write failed btrfs btrfs: disabling barriers on dev device

Commands:
Chapter 2. Support policy for Cryostat Red Hat supports a major version of Cryostat for a minimum of 6 months. Red Hat bases this figure on the time that the product gets released on the Red Hat Customer Portal. You can install and deploy Cryostat on Red Hat OpenShift Container Platform 4.8 or a later version that runs on an x86_64 architecture. Additional resources For more information about the Cryostat life cycle policy, see Red Hat build of Cryostat on the Red Hat OpenShift Container Platform Life Cycle Policy web page.

Commands:
Chapter 7. Configure Network Bonding Red Hat Enterprise Linux 7 allows administrators to bind multiple network interfaces together into a single, bonded, channel. Channel bonding enables two or more network interfaces to act as one, simultaneously increasing the bandwidth and providing redundancy. Warning The use of direct cable connections without network switches is not supported for bonding. The failover mechanisms described here will not work as expected without the presence of network switches. See the Red Hat Knowledgebase article Why is bonding in not supported with direct connection using crossover cables? for more information. Note The active-backup, balance-tlb and balance-alb modes do not require any specific configuration of the switch. Other bonding modes require configuring the switch to aggregate the links. For example, a Cisco switch requires EtherChannel for Modes 0, 2, and 3, but for Mode 4 LACP and EtherChannel are required. See the documentation supplied with your switch and see https://www.kernel.org/doc/Documentation/networking/bonding.txt 7.1. Understanding the Default Behavior of Controller and Port Interfaces When controlling bonded port interfaces using the NetworkManager daemon, and especially when fault finding, keep the following in mind: Starting the controller interface does not automatically start the port interfaces. Starting a port interface always starts the controller interface. Stopping the controller interface also stops the port interfaces. A controller without ports can start static IP connections. A controller without ports waits for ports when starting DHCP connections. A controller with a DHCP connection waiting for ports completes when a port with a carrier is added. A controller with a DHCP connection waiting for ports continues waiting when a port without a carrier is added.

Commands:
Chapter 98. OSGi EventAdmin Component Available as of Camel version 2.6 The eventadmin component can be used in an OSGi environment to receive OSGi EventAdmin events and process them. 98.1. Dependencies Maven users need to add the following dependency to their pom.xml <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-eventadmin</artifactId> <version>USD{camel-version}</version> </dependency> where USD{camel-version } must be replaced by the actual version of Camel (2.6.0 or higher). 98.2. URI format eventadmin:topic[?options] where topic is the name of the topic to listen too. 98.3. URI options The OSGi EventAdmin component supports 2 options, which are listed below. Name Description Default Type bundleContext (common) The OSGi BundleContext is automatic injected by Camel BundleContext resolveProperty Placeholders (advanced) Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. true boolean The OSGi EventAdmin endpoint is configured using URI syntax: with the following path and query parameters: 98.3.1. Path Parameters (1 parameters): Name Description Default Type topic Name of topic to listen or send to String 98.3.2. Query Parameters (5 parameters): Name Description Default Type send (common) Whether to use 'send' or 'synchronous' deliver. Default false (async delivery) false boolean bridgeErrorHandler (consumer) Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. false boolean exceptionHandler (consumer) To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. ExceptionHandler exchangePattern (consumer) Sets the exchange pattern when the consumer creates an exchange. ExchangePattern synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean 98.4. Message headers Name Type Message Description 98.5. Message body The in message body will be set to the received Event. 98.6. Example usage <route> <from uri="eventadmin:*"/> <to uri="stream:out"/> </route>

Commands:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-eventadmin</artifactId> <version>USD{camel-version}</version> </dependency>
eventadmin:topic[?options]
eventadmin:topic
<route> <from uri="eventadmin:*"/> <to uri="stream:out"/> </route>
6.4. Changing the Default Mapping In Red Hat Enterprise Linux, Linux users are mapped to the SELinux __default__ login by default (which is in turn mapped to the SELinux unconfined_u user). If you would like new Linux users, and Linux users not specifically mapped to an SELinux user to be confined by default, change the default mapping with the semanage login command. For example, enter the following command as root to change the default mapping from unconfined_u to user_u : Verify the __default__ login is mapped to user_u : If a new Linux user is created and an SELinux user is not specified, or if an existing Linux user logs in and does not match a specific entry from the semanage login -l output, they are mapped to user_u , as per the __default__ login. To change back to the default behavior, enter the following command as root to map the __default__ login to the SELinux unconfined_u user:

Commands:
~]# semanage login -m -S targeted -s "user_u" -r s0 __default__
~]# semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ user_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 *
~]# semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__
2.11. Source and View Metadata In addition to the distinction between business and technical metadata, it is necessary to know the difference between Source Metadata and View Metadata. Source and View metadata refers to what the metadata represents, not its content. Source Metadata directly represents metadata for an enterprise information system and captures exactly where and how the data is maintained. Source Metadata sounds similar to technical metadata, but Source Metadata can contain both technical and business metadata. When you model Source Metadata, you are modeling the data that your enterprise information systems contain. View Metadata, on the other hand, represent tailored views that transform the Source Metadata into the terminology and domain of different applications. View Metadata, too, can contain both technical and business metadata. When you model View Metadata, you are modeling the data as your applications (and your enterprise) ultimately use it.

Commands:
1.3. Storage Array Support By default, DM-Multipath includes support for the most common storage arrays that support DM-Multipath. The supported devices can be found in the multipath.conf.defaults file. If your storage array supports DM-Multipath and is not configured by default in this file, you may need to add them to the DM-Multipath configuration file, multipath.conf . For information on the DM-Multipath configuration file, see Chapter 4, The DM-Multipath Configuration File . Some storage arrays require special handling of I/O errors and path switching. These require separate hardware handler kernel modules.

Commands:
Part II. Subscription and Support To receive updates to the software on a Red Hat Enterprise Linux system it must be subscribed to the Red Hat Content Delivery Network ( CDN ) and the appropriate repositories enabled. This part describes how to subscribe a system to the Red Hat Content Delivery Network. Red Hat provides support via the Customer Portal , and you can access this support directly from the command line using the Red Hat Support Tool . This part describes the use of this command-line tool.

Commands:
D.2. Host Tags In a cluster configuration, you can define host tags in the configuration files. If you set hosttags = 1 in the tags section, a host tag is automatically defined using the machine's host name. This allows you to use a common configuration file which can be replicated on all your machines so they hold identical copies of the file, but the behavior can differ between machines according to the host name. For information on the configuration files, see Appendix B, The LVM Configuration Files . For each host tag, an extra configuration file is read if it exists: lvm_ hosttag. conf. If that file defines new tags, then further configuration files will be appended to the list of files to read in. For example, the following entry in the configuration file always defines tag1 , and defines tag2 if the host name is host1 .

Commands:
tags { tag1 { } tag2 { host_list = ["host1"] } }
7.4. PackageKit 7.4.1. RHBA-2015:1352 - PackageKit bug fix update Updated PackageKit packages that fix two 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# 1140837 Prior to this update, if the RPM v3 binary was used to re-sign custom and third-party unsigned packages, PackageKit could not handle installing these packages. As a consequence, installing certain packages using the PackageKit GUI could fail with the following error message: pct = div * (ts_current - 1) + pct_start + ((div / 100.0) * val) This update fixes PackageKit to handle these rare cases, and the installation no longer fails in the described situation. BZ# 1172119 Previously, when MAILTO recipients were set in the /etc/sysconfig/packagekit-background file, the /etc/cron.daily/packagekit-background.cron script only checked for the return value from the pkcon command before trying to send email reports. As a consequence, two unnecessary empty emails were sent under certain circumstances. With this update, the USDPKTMP file is not attempted to be sent by email if the files is empty, and only emails with useful information are now sent in the described scenario. Users of PackageKit are advised to upgrade to these updated packages, which fix these bugs.

Commands:
5.3.7. Removing Physical Volumes from a Volume Group To remove unused physical volumes from a volume group, use the vgreduce command. The vgreduce command shrinks a volume group's capacity by removing one or more empty physical volumes. This frees those physical volumes to be used in different volume groups or to be removed from the system. Before removing a physical volume from a volume group, you can make sure that the physical volume is not used by any logical volumes by using the pvdisplay command. If the physical volume is still being used you will have to migrate the data to another physical volume using the pvmove command. Then use the vgreduce command to remove the physical volume. The following command removes the physical volume /dev/hda1 from the volume group my_volume_group . If a logical volume contains a physical volume that fails, you cannot use that logical volume. To remove missing physical volumes from a volume group, you can use the --removemissing parameter of the vgreduce command, if there are no logical volumes that are allocated on the missing physical volumes.

Commands:
pvdisplay /dev/hda1 -- Physical volume --- PV Name /dev/hda1 VG Name myvg PV Size 1.95 GB / NOT usable 4 MB [LVM: 122 KB] PV# 1 PV Status available Allocatable yes (but full) Cur LV 1 PE Size (KByte) 4096 Total PE 499 Free PE 0 Allocated PE 499 PV UUID Sd44tK-9IRw-SrMC-MOkn-76iP-iftz-OVSen7
vgreduce my_volume_group /dev/hda1
probe::nfs.proc.write_done Name probe::nfs.proc.write_done - NFS client response to a write RPC task Synopsis nfs.proc.write_done Values server_ip IP address of server status result of last operation version NFS version count number of bytes written prot transfer protocol valid fattr->valid, indicates which fields are valid timestamp V4 timestamp, which is used for lease renewal Description Fires when a reply to a write RPC task is received or some write error occurs (timeout or socket shutdown).

Commands:
Chapter 7. Windows node upgrades You can ensure your Windows nodes have the latest updates by upgrading the Windows Machine Config Operator (WMCO). 7.1. Windows Machine Config Operator upgrades When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is upgraded based on the upgrade channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM). The WMCO upgrade results in the Kubernetes components in the Windows machine being upgraded. Note If you are upgrading to a new version of the WMCO and want to use cluster monitoring, you must have the openshift.io/cluster-monitoring=true label present in the WMCO namespace. If you add the label to a pre-existing WMCO namespace, and there are already Windows nodes configured, restart the WMCO pod to allow monitoring graphs to display. For a non-disruptive upgrade, the WMCO terminates the Windows machines configured by the version of the WMCO and recreates them using the current version. This is done by deleting the Machine object, which results in the drain and deletion of the Windows node. To facilitate an upgrade, the WMCO adds a version annotation to all the configured nodes. During an upgrade, a mismatch in version annotation results in the deletion and recreation of a Windows machine. To have minimal service disruptions during an upgrade, the WMCO only updates one Windows machine at a time. Important The WMCO is only responsible for updating Kubernetes components, not for Windows operating system updates. You provide the Windows image when creating the VMs; therefore, you are responsible for providing an updated image. You can provide an updated Windows image by changing the image configuration in the MachineSet spec. For more information on Operator upgrades using the Operator Lifecycle Manager (OLM), see Updating installed Operators .

Commands: