mtpti5iD/redhat-docs_dataset huggingface dataset:
16.10. Deleting and Resurrecting Entries This section describes how enabling synchronization affects deleted entries on the sync peers and how resurrected entries are handled. 16.10.1. Deleting Entries All changes on an Active Directory peers are always synchronized back to the Directory Server. This means that when an Active Directory group or user account is deleted on the Active Directory domain, the deletion is automatically synchronized back to the Directory Server sync peer server. On Directory Server, on the other hand, when a Directory Server account is deleted, the corresponding entry on Active Directory is only deleted if the Directory Server entry has the ntUserDeleteAccount or ntGroupDeleteGroup attribute set to true . Note When a Directory Server entry is synchronized over to Active Directory for the first time, Active Directory automatically assigns it a unique ID. At the synchronization interval, the unique ID is synchronized back to the Directory Server entry and stored as the ntUniqueId attribute. If the Directory Server entry is deleted on Active Directory before the unique ID is synchronized back to Directory Server, the entry will not be deleted on Directory Server. Directory Server uses the ntUniqueId attribute to identify and synchronize changes made on Active Directory to the corresponding Directory Server entry; without that attribute, Directory Server will not recognize the deletion. To delete the entry on Active Directory and then synchronize the deletion over to Directory Server, wait the length of the winSyncInterval (by default, five minutes) after the entry is created before deleting it so that the ntUniqueId attribute is synchronized. 16.10.2. Resurrecting Entries It is possible to add deleted entries back in Directory Server; the deleted entries are called tombstone entries. When a deleted entry which was synchronized between Directory Server and Active Directory is re-added to Directory Server, the resurrected Directory Server entry has all of its original attributes and values. This is called tombstone reanimation . The resurrected entry includes the original ntUniqueId attribute which was used to synchronize the entries, which signals to the Active Directory server that this new entry is a tombstone entry. Active Directory resurrects the old entry and preserves the original unique ID for the entry. For Active Directory entries, when the tombstone entry is resurrected on Directory Server, all of the attributes of the original Directory Server are retained and are still included in the resurrected Active Directory entry.

Commands:
Chapter 3. Adding subscriptions to a subscription allocation for a disconnected Satellite Server Only users on a disconnected Satellite Server need to add subscriptions to a subscription allocation. If you are a disconnected user, you must complete this step before you can download the manifest and add it to the host system. Users on a connected Satellite Server skip this step. For information about managing a subscription manifest for a connected Satellite Server, see Creating and managing a manifest for a connected Satellite Server . Procedure To add subscriptions to a subscription allocation for a disconnected Satellite Server, complete the following steps: From the Subscription Allocations page, click the allocation to which you are adding subscriptions. Click the Subscriptions tab. Click Add Subscriptions . Enter the number of entitlements for each subscription you plan to add. Ensure that you are adding the correct number of entitlements for the system you are using. Click Submit . Note You can include future-dated subscriptions, or subscriptions that have a start date in the future, to an allocation.

Commands:
Appendix B. Dashboard Builder B.1. JBoss Dashboard Builder JBoss Dashboard Builder is an open source dashboard and reporting tool that allows: Visual configuration and personalization of dashboards. Graphical representation of KPIs (Key Performance Indicators). Definition of interactive report tables. Filtering and search, both in-memory or database based. Process execution metrics dashboards. Data extraction from external systems, through different protocols. Access control for different user profiles to different levels of information.

Commands:
16.9. virt-inspector: Inspecting Guest Virtual Machines This section provides information about inspecting guest virtual machines using virt-inspector . 16.9.1. Introduction virt-inspector is a tool for inspecting a disk image to find out what operating system it contains. Note Red Hat Enterprise Linux 6.2 provides two variations of this program: virt-inspector is the original program as found in Red Hat Enterprise Linux 6.0 and is now deprecated upstream. virt-inspector2 is the same as the new upstream virt-inspector program.

Commands:
Chapter 7. Brokers page The Brokers page shows all the brokers created for a Kafka cluster. For each broker, you can see its status, as well as the distribution of partitions across the brokers, including the number of partition leaders and replicas. The broker status is shown as one of the following: Stable A stable broker is operating normally without significant issues. Unstable An unstable broker may be experiencing issues, such as high resource usage or network problems. If the broker has a rack ID, this is the ID of the rack or datacenter in which the broker resides. Click on the right arrow (>) to a broker name to see more information about the broker, including its hostname and disk usage. Note Consider rebalancing if the distribution is uneven to ensure efficient resource utilization.

Commands:
Chapter 2. Before you begin Initial setup Create an OpenShift instance. For more details on how to create an OpenShift instance, see OpenShift container platform installation overview . Version compatibility and support OpenShift Container Platform versions 3.11, 4.7, and above 4.7 support the S2I for OpenShift image. For details about the current support levels for OpenShift Container Platform, see Red Hat OpenShift Container Platform Life Cycle Policy and Red Hat OpenShift Container Platform Life Cycle Policy (non-current versions) .

Commands:
Appendix C. Understanding the node_replace_inventory.yml file The node_replace_inventory.yml file is an example Ansible inventory file that you can use to prepare a replacement host for your Red Hat Hyperconverged Infrastructure for Virtualization cluster. You can find this file at /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/node_replace_inventory.yml on any hyperconverged host. C.1. Configuration parameters for node replacement hosts (required) Defines one active host in the cluster using the back-end FQDN. gluster_maintenance_old_node (required) Defines the backend FQDN of the node being replaced. gluster_maintenance_new_node (required) Defines the backend FQDN of the replacement node. gluster_maintenance_cluster_node (required) An active node in the cluster. Cannot be the same as gluster_maintenance_cluster_node_2 . gluster_maintenance_cluster_node_2 (required) An active node in the cluster. Cannot be the same as gluster_maintenance_cluster_node . C.2. Example node_replace_inventory.yml

Commands:
cluster_nodes: hosts: host2-backend-fqdn.example.com : vars: [common host configuration]
cluster_nodes: hosts: host2-backend-fqdn.example.com : vars: gluster_maintenance_old_node: host1-backend-fqdn.example.com
cluster_nodes: hosts: host2-backend-fqdn.example.com : vars: gluster_maintenance_new_node: new-host-backend-fqdn.example.com
cluster_nodes: hosts: host2-backend-fqdn.example.com : vars: gluster_maintenance_cluster_node: host2-backend-fqdn.example.com
cluster_nodes: hosts: host2-backend-fqdn.example.com : vars: gluster_maintenance_cluster_node_2: host3-backend-fqdn.example.com
cluster_node: hosts: host2-backend-fqdn.example.com : vars: gluster_maintenance_old_node: host1-backend-fqdn.example.com gluster_maintenance_new_node: new-host-backend-fqdn.example.com gluster_maintenance_cluster_node: host2-backend-fqdn.example.com gluster_maintenance_cluster_node_2: host3-backend-fqdn.example.com
Chapter 29. Improving network latency using TCP_NODELAY By default, TCP uses Nagle's algorithm to collect small outgoing packets to send all at once. This can cause higher rates of latency. Prerequisites You have administrator privileges. 29.1. The effects of using TCP_NODELAY Applications that require low latency on every packet sent must be run on sockets with the TCP_NODELAY option enabled. This sends buffer writes to the kernel as soon as an event occurs. Note For TCP_NODELAY to be effective, applications must avoid doing small, logically related buffer writes. Otherwise, these small writes cause TCP to send these multiple buffers as individual packets, resulting in poor overall performance. If applications have several buffers that are logically related and must be sent as one packet, apply one of the following workarounds to avoid poor performance: Build a contiguous packet in memory and then send the logical packet to TCP on a socket configured with TCP_NODELAY . Create an I/O vector and pass it to the kernel using the writev command on a socket configured with TCP_NODELAY . Use the TCP_CORK option. TCP_CORK tells TCP to wait for the application to remove the cork before sending any packets. This command causes the buffers it receives to be appended to the existing buffers. This allows applications to build a packet in kernel space, which can be required when using different libraries that provide abstractions for layers. When a logical packet has been built in the kernel by the various components in the application, the socket should be uncorked, allowing TCP to send the accumulated logical packet immediately. 29.2. Enabling TCP_NODELAY The TCP_NODELAY option sends buffer writes to the kernel when events occur, with no delays. Enable TCP_NODELAY using the setsockopt() function. Procedure Add the following lines to the TCP application's .c file. Save the file and exit the editor. Apply one of the following workarounds to prevent poor performance. Build a contiguous packet in memory and then send the logical packet to TCP on a socket configured with TCP_NODELAY . Create an I/O vector and pass it to the kernel using writev on a socket configured with TCP_NODELAY . 29.3. Enabling TCP_CORK The TCP_CORK option prevents TCP from sending any packets until the socket is "uncorked". Procedure Add the following lines to the TCP application's .c file. Save the file and exit the editor. After the logical packet has been built in the kernel by the various components in the application, disable TCP_CORK . TCP sends the accumulated logical packet immediately, without waiting for any further packets from the application. 29.4. Additional resources tcp(7) , setsockopt(3p) , and setsockopt(2) man pages on your system

Commands:
int one = 1; setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));
int one = 1; setsockopt(descriptor, SOL_TCP, TCP_CORK, &one, sizeof(one));
int zero = 0; setsockopt(descriptor, SOL_TCP, TCP_CORK, &zero, sizeof(zero));
8.181. polkit 8.181.1. RHBA-2014:1533 - polkit bug fix and enhancement update The updated polkit packages that fix several bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. PolicyKit is a toolkit for defining and handling authorizations. Bug Fixes BZ# 628862 Previously, running the pkaction command with invalid arguments opened the corresponding manual page instead of generating a warning, or giving any other indication of erroneous behavior. With this update, the user is informed by an error message. BZ# 864613 Prior to this update, in PolicyKit local authority, the order of processing configuration files within a directory depended only on file system specifics. The ordering has been made consistent to avoid surprising changes in behavior but remains unspecified and may change in future updates of Red Hat Enterprise Linux; use the documented ordering of directory names if your configuration relies on ordering of the .pkla configuration files. BZ# 1132830 Prior to this update, if a process subject to an authorization query became a zombie before completing the authorization, the polkitd daemon could terminate unexpectedly. Handling of zombie processes has been improved to fix this crash. In addition, this update adds the following Enhancements BZ# 927406 With this update, all polkit binary files have been compiled with the RELRO option, and where applicable, with the PIE option, to increase resilience against various attacks. BZ# 812684 With this update, more flexibility in polkit rules is allowed. In addition to the existing "unix-user:" and "unix-group:" identity specifications, a new specification "default" can be used to specify authorization result for users that do not match either of the "unix-user:" or "unix-group:" specifications. Users of polkit are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

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

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
4.336. valgrind 4.336.1. RHBA-2011:1651 - valgrind bug fix and enhancement update Updated valgrind packages that fix several bugs and add an enhancement are available for Red Hat Enterprise Linux 6. Valgrind is a tool to help users find memory management problems in programs. Valgrind can detect a lot of problems that are otherwise very hard to find or diagnose. Bug Fixes BZ# 708522 When building the valgrind package with macros to prevent application of any downstream patches, the rebuild process failed. This bug has been fixed and valgrind can now be properly rebuilt in the described scenario. BZ# 713956 Previously, the JIT (Just in Time Compiler) in some versions of the JDK (Java Development Kit) generated useless, but valid, instruction prefixes, which valgrind could not emulate. Consequently, Java applications running under valgrind sometimes terminated unexpectedly. With this update, valgrind has been changed to emulate instructions even with these useless prefixes, the JVM process now exits properly, and valgrind displays memory leak summary information in the described scenario. BZ# 717218 In a Coverity Scan analysis, a redundant check was discovered in one of the backported patches applied to the valgrind package. An upstream patch has been applied to address this issue and the redundant check is no longer performed. Enhancement BZ# 694598 With this update, the valgrind package has been updated to provide support for 64-bit IBM POWER7 Series hardware. Users of valgrind are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 2. Partner onboarding Use the Red Hat Customer Portal to create a new account and to join the hardware certification program. If you face any issues during the certification process, you can contact us for support in any of the following ways. Create a Partner Acceleration Desk (PAD) ticket under the Product Certification category. Email the Red Hat Certification Operation (cert-ops) team at cert-ops@redhat.com . Contact your dedicated Ecosystem Partner Management (EPM) if you have been assigned one. 2.1. Creating a Red Hat account Procedure Open the Red Hat Customer Portal and click Register on the top-right corner of the page. The Register for a Red Hat account page displays. Note Make sure you use your company email ID and not your personal email. The email ID you enter will be used for all your communication with Red Hat going forward. Note Red Hat recommends using a unique login ID that is separate from the email ID to avoid account-related issues in the future. The login ID, once created, cannot be changed. Enter your Login information and Personal information . Select Corporate as the Account type. Enter your company's Contact information . Click Create My Account . A new Red Hat account is created. Request to enable Red Hat Partner Subscription (RHPS) on the same account. You must have an administrator organization (Org. Admins) rights to make a request. See Red Hat Partner Subscription (RHPS) for instructions. Verification Verify that an account number is assigned to your account. To do this, log in to your account at the Red Hat Customer Portal , and then click your avatar at the top-right to confirm the account details. 2.2. Join the hardware certification program Procedure Log in to the Red Hat Partner Connect portal to join the hardware certification program. Click Accept Terms and Conditions . Provide some more information about your company and product, and click Submit . Verify your email address by clicking on the link you received in your mailbox. On the Red Hat Terms and Conditions page, select all the I have read and agree to the terms check boxes, and click Submit . A message is displayed on successfully becoming a hardware partner. Select an option from the How will you use this subscription? drop-down list, and click Request partner subscription . On the Red Hat Terms and Conditions page, select all the I have read and agree to the terms check boxes, and click Submit . A message is displayed after successfully receiving a free partner subscription. A vendor profile is created and Single Sign-on (SSO) is automatically added to the vendor's users. Note Your vendor profile, once created, remains in the Red Hat database. However, your Red Hat Partner Subscription (RHPS) account becomes inactive after one year of inactivity. Therefore, if you are a returning partner, raise a request to reactivate your RHPS account before beginning hardware certification. Upon activating your RHPS account, the cert-ops team will be notified of your details, including Single Sign-on (SSO) information assigned to your account. Steps Opening a new certification case using the Red Hat Certification Tool

Commands:
Chapter 1. Overview Read this document to understand how to create, configure, and allocate storage to core services or hosted applications in Red Hat OpenShift Data Foundation. Chapter 2, Storage classes shows you how to create custom storage classes. Chapter 3, Block pools provides you with information on how to create, update and delete block pools. Chapter 4, Configure storage for OpenShift Container Platform services shows you how to use OpenShift Data Foundation for core OpenShift Container Platform services. Chapter 6, Backing OpenShift Container Platform applications with OpenShift Data Foundation provides information about how to configure OpenShift Container Platform applications to use OpenShift Data Foundation. Adding file and object storage to an existing external OpenShift Data Foundation cluster Chapter 8, How to use dedicated worker nodes for Red Hat OpenShift Data Foundation provides information about how to use dedicated worker nodes for Red Hat OpenShift Data Foundation. Chapter 9, Managing Persistent Volume Claims provides information about managing Persistent Volume Claim requests, and automating the fulfillment of those requests. Chapter 10, Reclaiming space on target volumes shows you how to reclaim the actual available storage space. Chapter 11, Volume Snapshots shows you how to create, restore, and delete volume snapshots. Chapter 12, Volume cloning shows you how to create volume clones. Chapter 13, Managing container storage interface (CSI) component placements provides information about setting tolerations to bring up container storage interface component on the nodes.

Commands:
Chapter 3. Running an Ansible playbook from Satellite You can run an Ansible playbook on a host or host group by executing a remote job in Satellite. Limitation of host parameters in Ansible playbook job templates When you execute an Ansible playbook on multiple hosts, Satellite renders the playbook for all hosts in the batch, but only uses the rendered playbook of the first host to execute it on all hosts in the batch. Therefore, you cannot modify the behavior of the playbook per host by using a host parameter in the template control flow constructs. Host parameters are translated into Ansible variables, so you can use them to control the behavior in native Ansible constructs. For more information, see BZ#2282275 . Prerequisites Ansible plugin in Satellite is enabled. Remote job execution is configured. For more information, see Chapter 4, Configuring and setting up remote jobs . You have an Ansible playbook ready to use. Procedure In the Satellite web UI, navigate to Monitor > Jobs . Click Run Job . In Job category , select Ansible Playbook . In Job template , select Ansible - Run playbook . Click . Select the hosts on which you want to run the playbook. In the playbook field, paste the content of your Ansible playbook. Follow the wizard to complete setting the remote job. For more information, see Section 4.21, "Executing a remote job" . Click Submit to run the Ansible playbook on your hosts. Additional resources Alternatively, you can import Ansible playbooks from Capsule Servers. For more information, see the following resources: Section 4.7, "Importing an Ansible playbook by name" Section 4.8, "Importing all available Ansible playbooks"

Commands: