mtpti5iD/redhat-docs_dataset huggingface dataset:
A.7. Troubleshooting Replication Test replication on at least two servers (see Section 4.6, "Testing the New Replica" ). If changes made on one IdM server are not replicated to the other server: Make sure you meet the conditions in Section 2.1.5, "Host Name and DNS Configuration" . Make sure that both servers can resolve each other's forward and reverse DNS records: Make sure that the time difference on both servers is 5 minutes at the most. Review the Directory Server error log on both servers: /var/log/dirsrv/slapd- SERVER-EXAMPLE-COM /errors . If you see errors related to Kerberos, make sure that the Directory Server keytab is correct and that you can use it to query the other server ( server2 in this example): Related Information See Section C.2, "Identity Management Log Files and Directories" for descriptions of various Identity Management log files.

Commands:
dig +short server2.example.com A dig +short server2.example.com AAAA dig +short -x server2_IPv4_or_IPv6_address
dig +short server1.example.com A dig +short server1.example.com AAAA dig +short -x server1_IPv4_or_IPv6_address
kinit -kt /etc/dirsrv/ds.keytab ldap/ server1.example.com klist ldapsearch -Y GSSAPI -h server1.example.com -b "" -s base ldapsearch -Y GSSAPI -h server2_FQDN . -b "" -s base
Chapter 1. Overview of Insights for Red Hat Enterprise Linux advisor service reporting The advisor service enables the following ways to share the status of your Red Hat Enterprise Linux (RHEL) infrastructure: Export and download a report (in CSV, JSON, or YAML file format) that shows recommendations for your impacted RHEL systems, and share the information with strategic stakeholders. Subscribe to the advisor Weekly Report email to receive a brief summary of the health of your RHEL environment. Download an executive report to share a high level overview of your infrastructure with an executive audience. These methods provide a quick and easily accessible way for you or other stakeholders to assess the health of your infrastructure and plan or act accordingly.

Commands:
Chapter 3. Enabling NVIDIA GPUs Before you can use NVIDIA GPUs in OpenShift AI, you must install the NVIDIA GPU Operator. Prerequisites You have logged in to your OpenShift cluster. You have the cluster-admin role in your OpenShift cluster. You have installed an NVIDIA GPU and confirmed that it is detected in your environment. Procedure To enable GPU support on an OpenShift cluster in a disconnected or airgapped environment, follow the instructions here: Deploy GPU Operators in a disconnected or airgapped environment in the NVIDIA documentation. Important After you install the Node Feature Discovery (NFD) Operator, you must create an instance of NodeFeatureDiscovery. In addition, after you install the NVIDIA GPU Operator, you must create a ClusterPolicy and populate it with default values. Delete the migration-gpu-status ConfigMap. In the OpenShift web console, switch to the Administrator perspective. Set the Project to All Projects or redhat-ods-applications to ensure you can see the appropriate ConfigMap. Search for the migration-gpu-status ConfigMap. Click the action menu (...) and select Delete ConfigMap from the list. The Delete ConfigMap dialog appears. Inspect the dialog and confirm that you are deleting the correct ConfigMap. Click Delete . Restart the dashboard replicaset. In the OpenShift web console, switch to the Administrator perspective. Click Workloads Deployments . Set the Project to All Projects or redhat-ods-applications to ensure you can see the appropriate deployment. Search for the rhods-dashboard deployment. Click the action menu (...) and select Restart Rollout from the list. Wait until the Status column indicates that all pods in the rollout have fully restarted. Verification The reset migration-gpu-status instance is present on the Instances tab on the AcceleratorProfile custom resource definition (CRD) details page. From the Administrator perspective, go to the Operators Installed Operators page. Confirm that the following Operators appear: NVIDIA GPU Node Feature Discovery (NFD) Kernel Module Management (KMM) The GPU is correctly detected a few minutes after full installation of the Node Feature Discovery (NFD) and NVIDIA GPU Operators. The OpenShift command line interface (CLI) displays the appropriate output for the GPU worker node. For example: Note In OpenShift AI 2.18, Red Hat supports the use of accelerators within the same cluster only. Red Hat does not support remote direct memory access (RDMA) between accelerators, or the use of accelerators across a network, for example, by using technology such as NVIDIA GPUDirect or NVLink. After installing the NVIDIA GPU Operator, create an accelerator profile as described in Working with accelerator profiles .

Commands:
Expected output when the GPU is detected properly describe node <node name> Capacity: cpu: 4 ephemeral-storage: 313981932Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 16076568Ki nvidia.com/gpu: 1 pods: 250 Allocatable: cpu: 3920m ephemeral-storage: 288292006229 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 12828440Ki nvidia.com/gpu: 1 pods: 250
8.215. sg3_utils 8.215.1. RHBA-2014:1601 - sg3_utils bug fix update Updated sg3_utils packages that fix one bug are now available for Red Hat Enterprise Linux 6. The sg3_utils packages contain a collection of tools for SCSI devices that use the Linux SCSI generic (sg) interface. This collection includes utilities for database copying based on "dd" syntax and semantics (the "sg_dd", "sgp_dd" and "sgm_dd" commands), INQUIRY data checking and associated pages ("sg_inq"), mode and log page checking ("sg_modes" and "sg_logs"), disk spinning ("sg_start") and self-tests ("sg_senddiag"), as well as other utilities. It also contains the rescan-scsi-bus.sh script. Bug Fix BZ# 857200 When a Logical Unit Number (LUN) was resized on a target side, the rescan-scsi-bus.sh script failed to resize SCSI devices on the host side. This update applies a patch to fix this bug and when an LUN is resized on the target side, the change is propagated to the host side as expected. Users of sg3_utils are advised to upgrade to these updated packages, which fix this bug.

Commands:
Providing feedback on Red Hat build of OpenJDK documentation To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account. Procedure Click the following link to create a ticket . Enter a brief description of the issue in the Summary . Provide a detailed description of the issue or enhancement in the Description . Include a URL to where the issue occurs in the documentation. Clicking Create creates and routes the issue to the appropriate documentation team.

Commands:
probe::nfs.proc.lookup Name probe::nfs.proc.lookup - NFS client opens/searches a file on server Synopsis nfs.proc.lookup Values bitmask1 V4 bitmask representing the set of attributes supported on this filesystem bitmask0 V4 bitmask representing the set of attributes supported on this filesystem filename the name of file which client opens/searches on server server_ip IP address of server prot transfer protocol name_len the length of file name version NFS version

Commands:
Chapter 13. The Hot Rod Interface 13.1. About Hot Rod Hot Rod is a binary TCP client-server protocol used in Red Hat JBoss Data Grid. It was created to overcome deficiencies in other client/server protocols, such as Memcached. Hot Rod will failover on a server cluster that undergoes a topology change. Hot Rod achieves this by providing regular updates to clients about the cluster topology. Hot Rod enables clients to do smart routing of requests in partitioned or distributed JBoss Data Grid server clusters. To do this, Hot Rod allows clients to determine the partition that houses a key and then communicate directly with the server that has the key. This functionality relies on Hot Rod updating the cluster topology with clients, and that the clients use the same consistent hash algorithm as the servers. JBoss Data Grid contains a server module that implements the Hot Rod protocol. The Hot Rod protocol facilitates faster client and server interactions in comparison to other text-based protocols and allows clients to make decisions about load balancing, failover and data location operations. Report a bug

Commands:
8.9. akonadi 8.9.1. RHBA-2014:0539 - akonadi bug fix update Updated akonadi packages that fix one bug are now available for Red Hat Enterprise Linux 6. Akonadi is a storage service for personal information management (PIM) data and metadata. The service provides unique desktop-wide object identification and retrieval, and functions as an extensible data storage for all PIM applications. Bug Fix BZ# 1073939 Previously, the Akonadi service used the hard-coded ~/.local/share/akonadi socket directory. As a consequence, the Akonadi server did not start if the home directory was located on Andrew File System (AFS), which did not support the creation of UNIX sockets. With this update, the directory that holds the sockets has been changed to '/tmp/[username]-akonadi.[random]'. As a result, Akonadi starts on systems with the home directory on AFS as expected. Users of akonadi are advised to upgrade to these updated packages, which fix this bug.

Commands:
5.151. libhbalinux 5.151.1. RHEA-2012:0848 - libhbalinux enhancement update An updated libhbalinux package that fixes multiple bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The libhbalinux package contains the Host Bus Adapter API (HBAAPI) vendor library which uses standard kernel interfaces to obtain information about Fiber Channel Host Buses (FC HBA) in the system. The libhbalinux packages have been upgraded to upstream version 1.0.13, which provides a number of bug fixes and enhancements over the version. (BZ# 719584 ) All users of libhbalinux are advised to upgrade to this updated libhbalinux package, which fixes these bugs and adds these enhancements.

Commands:
Chapter 17. configuration This chapter describes the commands under the configuration command. 17.1. configuration show Display configuration details Usage: Table 17.1. Command arguments Value Summary -h, --help Show this help message and exit --mask Attempt to mask passwords (default) --unmask Show password in clear text Table 17.2. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns Table 17.3. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 17.4. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 17.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack configuration show [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] [--mask | --unmask]
3.5. Configuring FTP File Transport Protocol (FTP) is an old and complex multi-port protocol that presents a distinct set of challenges to an Load Balancer Add-On environment. To understand the nature of these challenges, you must first understand some key things about how FTP works. 3.5.1. How FTP Works With most other server client relationships, the client machine opens up a connection to the server on a particular port and the server then responds to the client on that port. When an FTP client connects to an FTP server it opens a connection to the FTP control port 21. Then the client tells the FTP server whether to establish an active or passive connection. The type of connection chosen by the client determines how the server responds and on what ports transactions will occur. The two types of data connections are: Active Connections When an active connection is established, the server opens a data connection to the client from port 20 to a high range port on the client machine. All data from the server is then passed over this connection. Passive Connections When a passive connection is established, the client asks the FTP server to establish a passive connection port, which can be on any port higher than 10,000. The server then binds to this high-numbered port for this particular session and relays that port number back to the client. The client then opens the newly bound port for the data connection. Each data request the client makes results in a separate data connection. Most modern FTP clients attempt to establish a passive connection when requesting data from servers. Note The client determines the type of connection, not the server. This means to effectively cluster FTP, you must configure the LVS routers to handle both active and passive connections. The FTP client-server relationship can potentially open a large number of ports that the Piranha Configuration Tool and IPVS do not know about.

Commands:
Chapter 2. Installation This section outlines the differences between Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 5 installation procedures. Depending on which release of Red Hat Enterprise Linux 5 you are migrating from, not all of the options and techniques listed here will be relevant to your environment, as they might already be present in your Red Hat Enterprise Linux 5 environment. 2.1. Kernel and Boot Options You can perform memory testing before you install Red Hat Enterprise Linux by entering memtest86 at the boot: prompt. This option runs the Memtest86 stand alone memory testing software in place of the Anaconda system installer. Once started, Memtest86 memory testing loops continually until the Esc key is pressed. The rdloaddriver kernel parameter is now needed to define the order of module loading, instead of the old scsi_hostadapter option. Kernel Modesetting (KMS) is a feature that assigns the responsibility of graphics mode initialization to the kernel, and is enabled by default. KMS enables: Improved graphical boot. Faster fast user switching. Seamless X server switching. Graphical panic messages. KMS can be disabled for all drivers by appending nomodeset to the boot: line when booting the system.

Commands:
Chapter 6. Administer Micrometer in JBoss EAP 6.1. Adding Micrometer subsystem using the Management CLI The Micrometer subsystem enhances monitoring capabilities in JBoss EAP by facilitating comprehensive metrics gathering and publication. However, the org.jboss.extension.micrometer subsystem is available to all standalone configurations within the JBoss EAP distribution, but it must be added manually. Prerequisites JBoss EAP 8.0 with JBoss EAP XP 5.0 is installed. You have access to the JBoss EAP management CLI and permissions to make configuration changes. Procedure Open your terminal. Connect to the server by running the following command: Check if the Micrometer extension is already added to the configuration by running the following command: If the Micrometer extension is not available, add it by running the following command: Add the Micrometer subsystem with the required configuration. For example, specify the endpoint URL of the metrics collector by running the following command: Reload the server to apply the changes: Note When the collector is not running or its collector endpoint is unavailable, then a warning message similar to the following is triggered: By following these steps, you can add the Micrometer subsystem to your JBoss EAP server using the management CLI, enabling enhanced monitoring capabilities for your applications. Additional resources Develop Micrometer application for JBoss EAP

Commands:
./jboss-cli.sh --connect
[standalone@localhost:9990 /] /extension=org.wildfly.extension.micrometer:read-resource
[standalone@localhost:9990 /] /extension=org.wildfly.extension.micrometer:add
[standalone@localhost:9990 /] /subsystem=micrometer:add(endpoint="http://localhost:4318/v1/metrics")
[standalone@localhost:9990 /] reload
11:28:16,581 WARNING [io.micrometer.registry.otlp.OtlpMeterRegistry] (MSC service thread 1-5) Failed to publish metrics to OTLP receiver: java.net.ConnectException: Connection refused
Appendix B. Revision History Revision History Revision 1-43 Fri Feb 7 2020 Jan Fiala Async release with an update of the Compliance and Vulnerability Scanning chapter. Revision 1-42 Fri Aug 9 2019 Mirek Jahoda Version for 7.7 GA publication. Revision 1-41 Sat Oct 20 2018 Mirek Jahoda Version for 7.6 GA publication. Revision 1-32 Wed Apr 4 2018 Mirek Jahoda Version for 7.5 GA publication. Revision 1-30 Thu Jul 27 2017 Mirek Jahoda Version for 7.4 GA publication. Revision 1-24 Mon Feb 6 2017 Mirek Jahoda Async release with misc. updates, especially in the firewalld section. Revision 1-23 Tue Nov 1 2016 Mirek Jahoda Version for 7.3 GA publication. Revision 1-19 Mon Jul 18 2016 Mirek Jahoda The Smart Cards section added. Revision 1-18 Mon Jun 27 2016 Mirek Jahoda The OpenSCAP-daemon and Atomic Scan section added. Revision 1-17 Fri Jun 3 2016 Mirek Jahoda Async release with misc. updates. Revision 1-16 Tue Jan 5 2016 Robert Kratky Post 7.2 GA fixes. Revision 1-15 Tue Nov 10 2015 Robert Kratky Version for 7.2 GA release. Revision 1-14.18 Mon Nov 09 2015 Robert Kratky Async release with misc. updates. Revision 1-14.17 Wed Feb 18 2015 Robert Kratky Version for 7.1 GA release. Revision 1-14.15 Fri Dec 06 2014 Robert Kratky Update to sort order on the Red Hat Customer Portal. Revision 1-14.13 Thu Nov 27 2014 Robert Kratky Updates reflecting the POODLE vuln. Revision 1-14.12 Tue Jun 03 2014 Tomas Capek Version for 7.0 GA release.

Commands:
20.3. Quota Accounting When a quota is assigned to a consumer or a resource, each action by that consumer or on the resource involving storage, vCPU, or memory results in quota consumption or quota release. Since the quota acts as an upper bound that limits the user's access to resources, the quota calculations may differ from the actual current use of the user. The quota is calculated for the max growth potential and not the current usage. Example 20.1. Accounting example A user runs a virtual machine with 1 vCPU and 1024 MB memory. The action consumes 1 vCPU and 1024 MB of the quota assigned to that user. When the virtual machine is stopped 1 vCPU and 1024 MB of RAM are released back to the quota assigned to that user. Run-time quota consumption is accounted for only during the actual run-time of the consumer. A user creates a virtual thin provision disk of 10 GB. The actual disk usage may indicate only 3 GB of that disk are actually in use. The quota consumption, however, would be 10 GB, the max growth potential of that disk.

Commands:
Chapter 105. KafkaUserTlsExternalClientAuthentication schema reference Used in: KafkaUserSpec The type property is a discriminator that distinguishes use of the KafkaUserTlsExternalClientAuthentication type from KafkaUserTlsClientAuthentication , KafkaUserScramSha512ClientAuthentication . It must have the value tls-external for the type KafkaUserTlsExternalClientAuthentication . Property Property type Description type string Must be tls-external .

Commands:
Chapter 40. Compiler and Tools Shenandoah garbage collector The new, low pause time Shenandoah garbage collector, is now available as a Technology Preview for OpenJDK on the Intel 64, AMD64, and 64-bit ARM architectures. Shenandoah performs concurrent evacuation which allows users to run with large heaps without long pause times. For more information, see https://wiki.openjdk.java.net/display/shenandoah/Main . (BZ#1400306)

Commands:
5.2.14. /proc/kcore This file represents the physical memory of the system and is stored in the core file format. Unlike most /proc/ files, kcore displays a size. This value is given in bytes and is equal to the size of the physical memory (RAM) used plus 4 KB. The contents of this file are designed to be examined by a debugger, such as gdb , and is not human readable. Warning Do not view the /proc/kcore virtual file. The contents of the file scramble text output on the terminal. If this file is accidentally viewed, press Ctrl + C to stop the process and then type reset to bring back the command line prompt.

Commands:
Chapter 34. Preparing your environment for managing IdM using Ansible playbooks As a system administrator managing Identity Management (IdM), when working with Red Hat Ansible Engine, it is good practice to do the following: Create a subdirectory dedicated to Ansible playbooks in your home directory, for example ~/MyPlaybooks . Copy and adapt sample Ansible playbooks from the /usr/share/doc/ansible-freeipa/* and /usr/share/doc/rhel-system-roles/* directories and subdirectories into your ~/MyPlaybooks directory. Include your inventory file in your ~/MyPlaybooks directory. Using this practice, you can find all your playbooks in one place and you can run your playbooks without invoking root privileges. Note You only need root privileges on the managed nodes to execute the ipaserver , ipareplica , ipaclient and ipabackup ansible-freeipa roles. These roles require privileged access to directories and the dnf software package manager. Follow this procedure to create the ~/MyPlaybooks directory and configure it so that you can use it to store and run Ansible playbooks. Prerequisites You have installed an IdM server on your managed nodes, server.idm.example.com and replica.idm.example.com . You have configured DNS and networking so you can log in to the managed nodes, server.idm.example.com and replica.idm.example.com , directly from the control node. You know the IdM admin password. Procedure Create a directory for your Ansible configuration and playbooks in your home directory: Change into the ~/MyPlaybooks/ directory: Create the ~/MyPlaybooks/ansible.cfg file with the following content: Create the ~/MyPlaybooks/inventory file with the following content: This configuration defines two host groups, eu and us , for hosts in these locations. Additionally, this configuration defines the ipaserver host group, which contains all hosts from the eu and us groups. Optional: Create an SSH public and private key. To simplify access in your test environment, do not set a password on the private key: Copy the SSH public key to the IdM admin account on each managed node: These commands require that you enter the IdM admin password. Additional resources Installing an Identity Management server using an Ansible playbook How to build your inventory

Commands:
mkdir ~/MyPlaybooks/
cd ~/MyPlaybooks
[defaults] inventory = /home/ your_username /MyPlaybooks/inventory [privilege_escalation] become=True
[eu] server.idm.example.com [us] replica.idm.example.com [ipaserver:children] eu us
ssh-keygen
ssh-copy-id admin@server.idm.example.com ssh-copy-id admin@replica.idm.example.com
A.2. PCP Deployment To monitor an entire cluster, the recommended approach is to install and configure PCP so that the GFS2 PMDA is enabled and loaded on each node of the cluster along with any other PCP services. You will then be able to monitor nodes either locally or remotely on a machine that has PCP installed with the corresponding PMDAs loaded in monitor mode. You may also install the optional pcp-gui package to allow graphical representation of trace data through the pmchart tool For additional information, see the pcp-doc package, which is installed to /usr/share/doc/pcp-doc by default. PCP also provides a man page for every tool.

Commands: