mtpti5iD/redhat-docs_dataset huggingface dataset:
12.8. Removing an Attribute This section describes how to delete an attribute using the command line and the web console. 12.8.1. Removing an Attribute Using the Command Line Use the ldapmodify utility to delete an attribute. For example: Remove the unwanted attributes from any entries which use them. Delete the attribute: For further details about object class definitions, see Section 12.1.2, "Object Classes" . 12.8.2. Removing an Attribute Using the Web Console To remove an attribute using the web console: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Select Schema Objectclasses . Click the Choose Action button to the attribute you want to remove. Select Delete Attribute . Click Yes to confirm.

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com schema attributetypes remove dateofbirth
Chapter 17. Berkeley Internet Name Domain BIND performs name resolution services using the named daemon. BIND lets users locate computer resources and services by name instead of numerical addresses. In Red Hat Enterprise Linux, the bind package provides a DNS server. Enter the following command to see if the bind package is installed: If it is not installed, use the yum utility as the root user to install it: 17.1. BIND and SELinux The default permissions on the /var/named/slaves/ , /var/named/dynamic/ and /var/named/data/ directories allow zone files to be updated using zone transfers and dynamic DNS updates. Files in /var/named/ are labeled with the named_zone_t type, which is used for master zone files. For a slave server, configure the /etc/named.conf file to place slave zones in /var/named/slaves/ . The following is an example of a domain entry in /etc/named.conf for a slave DNS server that stores the zone file for testdomain.com in /var/named/slaves/ : If a zone file is labeled named_zone_t , the named_write_master_zones Boolean must be enabled to allow zone transfers and dynamic DNS to update the zone file. Also, the mode of the parent directory has to be changed to allow the named user or group read, write and execute access. If zone files in /var/named/ are labeled with the named_cache_t type, a file system relabel or running restorecon -R /var/ will change their type to named_zone_t .

Commands:
~]USD rpm -q bind package bind is not installed
~]# yum install bind
zone "testdomain.com" { type slave; masters { IP-address; }; file "/var/named/slaves/db.testdomain.com"; };
5.3. Minor version updates of RHGS 3.5.z For RHGS 3.5.z minor version updates on RHEL 7 and RHEL 8, follow the procedure described in Section 5.2, "In-Service Software Upgrade from Red Hat Gluster Storage 3.4 to Red Hat Gluster Storage 3.5" Note In the case of kernel updates make sure to reboot the host after software update is completed.

Commands:
Chapter 5. Using feature gates in a hosted cluster You can use feature gates in a hosted cluster to enable features that are not part of the default set of features. You can enable the TechPreviewNoUpgrade feature set by using feature gates in your hosted cluster. 5.1. Enabling feature sets by using feature gates You can enable the TechPreviewNoUpgrade feature set in a hosted cluster by editing the HostedCluster custom resource (CR) with the OpenShift CLI. Prerequisites You installed the OpenShift CLI ( oc ). Procedure Open the HostedCluster CR for editing on the hosting cluster by running the following command: USD oc edit <hosted_cluster_name> -n <hosted_cluster_namespace> Define the feature set by entering a value in the featureSet field. For example: apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: <hosted_cluster_name> 1 namespace: <hosted_cluster_namespace> 2 spec: configuration: featureGate: featureSet: TechPreviewNoUpgrade 3 1 Specifies your hosted cluster name. 2 Specifies your hosted cluster namespace. 3 This feature set is a subset of the current Technology Preview features. Warning Enabling the TechPreviewNoUpgrade feature set on your cluster cannot be undone and prevents minor version updates. This feature set allows you to enable these Technology Preview features on test clusters, where you can fully test them. Do not enable this feature set on production clusters. Save the file to apply the changes. Verification Verify that the TechPreviewNoUpgrade feature gate is enabled in your hosted cluster by running the following command: USD oc get featuregate cluster -o yaml Additional resources FeatureGate [config.openshift.io/v1 ]

Commands:
oc edit <hosted_cluster_name> -n <hosted_cluster_namespace>
apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: <hosted_cluster_name> 1 namespace: <hosted_cluster_namespace> 2 spec: configuration: featureGate: featureSet: TechPreviewNoUpgrade 3
oc get featuregate cluster -o yaml
Chapter 4. Tuna You can use the Tuna tool to adjust scheduler tunables, tune thread priority, IRQ handlers, and isolate CPU cores and sockets. Tuna aims to reduce the complexity of performing tuning tasks. After installing the tuna package, use the tuna command without any arguments to start the Tuna graphical user interface (GUI). Use the tuna -h command to display available command-line interface (CLI) options. Note that the tuna (8) manual page distinguishes between action and modifier options. The Tuna GUI and CLI provide equivalent functionality. The GUI displays the CPU topology on one screen to help you identify problems. The Tuna GUI also allows you to make changes to the running threads, and see the results of those changes immediately. In the CLI, Tuna accepts multiple command-line parameters and processes them sequentially. You can use such commands in application initialization scripts as configuration commands. The Monitoring tab of the Tuna GUI Important Use the tuna --save= filename command with a descriptive file name to save the current configuration. Note that this command does not save every option that Tuna can change, but saves the kernel thread changes only. Any processes that are not currently running when they are changed are not saved. 4.1. Reviewing the System with Tuna Before you make any changes, you can use Tuna to show you what is currently happening on the system. To view the current policies and priorities, use the tuna --show_threads command: To show only a specific thread corresponding to a PID or matching a command name, add the --threads option before --show_threads : The pid_or_cmd_list argument is a list of comma-separated PIDs or command-name patterns. To view the current interrupt requests (IRQs) and their affinity, use the tuna --show_irqs command: To show only a specific interrupt request corresponding to an IRQ number or matching an IRQ user name, add the --irqs option before --show_irqs : The number_or_user_list argument is a list of comma-separated IRQ numbers or user-name patterns.

Commands:
tuna --show_threads thread pid SCHED_ rtpri affinity cmd 1 OTHER 0 0,1 init 2 FIFO 99 0 migration/0 3 OTHER 0 0 ksoftirqd/0 4 FIFO 99 0 watchdog/0
tuna --threads= pid_or_cmd_list --show_threads
tuna --show_irqs users affinity 0 timer 0 1 i8042 0 7 parport0 0
tuna --irqs= number_or_user_list --show_irqs
Chapter 1. Using cost management currency exchange Cost management uses the United States Dollar (USD) by default. However, you can use the cost management currency exchange feature to estimate your costs in your local currency. This feature updates costs both in Red Hat Hybrid Cloud Console and in your exported cost report files. Cost management updates currency exchange information daily with the most recent data from ExchangeRate-API . The values in cost management do not reflect any foreign currency contract agreements. Procedure From Red Hat Hybrid Cloud Console go to cost management . From the currency dropdown, select your local currency. After you change your currency, cost management automatically updates all values with the most recent exchange rates.

Commands:
Chapter 50. EntityOperatorTemplate schema reference Used in: EntityOperatorSpec Property Description deployment Template for Entity Operator Deployment . DeploymentTemplate pod Template for Entity Operator Pods . PodTemplate topicOperatorContainer Template for the Entity Topic Operator container. ContainerTemplate userOperatorContainer Template for the Entity User Operator container. ContainerTemplate tlsSidecarContainer Template for the Entity Operator TLS sidecar container. ContainerTemplate serviceAccount Template for the Entity Operator service account. ResourceTemplate entityOperatorRole Template for the Entity Operator Role. ResourceTemplate topicOperatorRoleBinding Template for the Entity Topic Operator RoleBinding. ResourceTemplate userOperatorRoleBinding Template for the Entity Topic Operator RoleBinding. ResourceTemplate

Commands:
Chapter 13. Installing a three-node cluster on GCP In OpenShift Container Platform version 4.17, you can install a three-node cluster on Google Cloud Platform (GCP). 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. 13.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 user-provisioned infrastructure in GCP by using Deployment Manager 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: {} 13.2. steps Installing a cluster on GCP with customizations Installing a cluster on user-provisioned infrastructure in GCP by using Deployment Manager 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: {}
Chapter 15. KVM Migration This chapter covers the migration guest virtual machines from one host physical machine that runs the KVM hypervisor to another. Migrating guests is possible because virtual machines run in a virtualized environment instead of directly on the hardware. 15.1. Migration Definition and Benefits Migration works by sending the state of the guest virtual machine's memory and any virtualized devices to a destination host physical machine. It is recommended to use shared, networked storage to store the guest's images to be migrated. It is also recommended to use libvirt-managed storage pools for shared storage when migrating virtual machines. Migrations can be performed both with live (running) and non-live (shut-down) guests. In a live migration , the guest virtual machine continues to run on the source host machine, while the guest's memory pages are transferred to the destination host machine. During migration, KVM monitors the source for any changes in pages it has already transferred, and begins to transfer these changes when all of the initial pages have been transferred. KVM also estimates transfer speed during migration, so when the remaining amount of data to transfer reaches a certain configurable period of time (10ms by default), KVM suspends the original guest virtual machine, transfers the remaining data, and resumes the same guest virtual machine on the destination host physical machine. In contrast, a non-live migration (offline migration) suspends the guest virtual machine and then copies the guest's memory to the destination host machine. The guest is then resumed on the destination host machine and the memory the guest used on the source host machine is freed. The time it takes to complete such a migration only depends on network bandwidth and latency. If the network is experiencing heavy use or low bandwidth, the migration will take much longer. Note that if the original guest virtual machine modifies pages faster than KVM can transfer them to the destination host physical machine, offline migration must be used, as live migration would never complete. Migration is useful for: Load balancing Guest virtual machines can be moved to host physical machines with lower usage if their host machine becomes overloaded, or if another host machine is under-utilized. Hardware independence When you need to upgrade, add, or remove hardware devices on the host physical machine, you can safely relocate guest virtual machines to other host physical machines. This means that guest virtual machines do not experience any downtime for hardware improvements. Energy saving Virtual machines can be redistributed to other host physical machines, and the unloaded host systems can thus be powered off to save energy and cut costs in low usage periods. Geographic migration Virtual machines can be moved to another location for lower latency or when required by other reasons.

Commands:
Appendix A. Component Versions This appendix provides a list of key components and their versions in the Red Hat Enterprise Linux 7.6 release. Table A.1. Component Versions Component Version kernel 3.10.0-957 kernel-alt 4.14.0-115 QLogic qla2xxx driver 10.00.00.06.07.6-k QLogic qla4xxx driver 5.04.00.00.07.02-k0 Emulex lpfc driver 0:12.0.0.5 iSCSI initiator utils ( iscsi-initiator-utils ) 6.2.0.874-10 DM-Multipath ( device-mapper-multipath ) 0.4.9-123 LVM ( lvm2 ) 2.02.180-8 qemu-kvm [a] 1.5.3-160 qemu-kvm-ma [b] 2.12.0-18 [a] The qemu-kvm packages provide KVM virtualization on AMD64 and Intel 64 systems. [b] The qemu-kvm-ma packages provide KVM virtualization on IBM POWER8, IBM POWER9, and IBM Z. Note that KVM virtualization on IBM POWER9 and IBM Z also requires using the kernel-alt packages.

Commands:
A.17. libguestfs Troubleshooting A test tool is available to check that libguestfs is working. Enter the following command after installing libguestfs (root access not required) to test for normal operation: This tool prints a large amount of text to test the operation of libguestfs. If the test is successful, the following text will appear near the end of the output:

Commands:
libguestfs-test-tool
===== TEST FINISHED OK =====
Chapter 2. Certification prerequisites Note A strong working knowledge of Red Hat Enterprise Linux and Red Hat OpenStack is required. A Red Hat Certified Engineer and a Red Hat OpenStack Platform Certified Engineer accreditation is preferred and suggested before participating. 2.1. Partner eligibility criteria Ensure to meet the following requirements before applying for a Red Hat bare-metal hardware certification: You are part of the Red Hat Hardware Certification program . You are in a support relationship with Red Hat by means of the TSANet network or a custom support agreement. 2.2. Certification targets The certification targets provide details and requirements about the components and products relevant to the certification. Specific information for each of the certification components is provided when applicable. 2.2.1. Server Ensure that the server must have the following certifications: Red Hat Enterprise Linux System Red Hat OpenStack Platform Compute Node Each certification is keyed to the specific Cloud Platform product version and its associated ironic revision. You can certify your server for RHOSP, if your hardware is compatible with the ironic drivers for that platform. The server must have a baseboard management controller (BMC) installed. 2.2.2. Red Hat Cloud Platform Products Bare-metal certification Through this program you can certify BMC and bare-metal servers on Red Hat OpenStack Platform 17.1. 2.2.3. Baseboard management controllers (BMC) A BMC is a specialized microcontroller on a server's motherboard that manages the interface between systems management software and physical hardware. The bare metal service in Red Hat Platforms provisions systems in a cluster by using the BMC to control power, network booting, and automate node deployment and termination. BMC can be certified as a component for use in leveraging components, across multiple server systems. Similar to Red Hat Hardware Certification programs, Red Hat leverages partners' internal quality testing to streamline the certification process without adding risk to customer environments. Red Hat recommends partners using component leveraging features in bare-metal hardware certifications conduct their testing with the specific server system, BMC, and Red Hat cloud platform product to validate each combination. However, you do not need to submit individual certification results to Red Hat for every combination. 2.2.4. Bare Metal Drivers IPI component certification BMCs must use supported Red Hat OpenStack Platform Bare Metal Drivers provided in the corresponding Red Hat Cloud platform product. You cannot certify a BMC that requires an ironic driver that is not included in the Red Hat product.

Commands:
22.5. UTC, Timezones, and DST As NTP is entirely in UTC (Universal Time, Coordinated), Timezones and DST (Daylight Saving Time) are applied locally by the system. The file /etc/localtime is a copy of, or symlink to, a zone information file from /usr/share/zoneinfo . The RTC may be in localtime or in UTC, as specified by the 3rd line of /etc/adjtime , which will be one of LOCAL or UTC to indicate how the RTC clock has been set. Users can easily change this setting using the check box System Clock Uses UTC in the system-config-date graphical configuration tool. See Chapter 2, Date and Time Configuration for information on how to use that tool. Running the RTC in UTC is recommended to avoid various problems when daylight saving time is changed. The operation of ntpd is explained in more detail in the man page ntpd(8) . The resources section lists useful sources of information. See Section 22.19, "Additional Resources" .

Commands:
Chapter 88. Mail Microsoft Oauth Since Camel 3.18.4 . The Mail Microsoft OAuth2 provides an implementation of org.apache.camel.component.mail.MailAuthenticator to authenticate IMAP/POP/SMTP connections and access to Email via Spring's Mail support and the underlying JavaMail system. 88.1. Dependencies Add the following dependency to your pom.xml for this component: <dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-mail-microsoft-oauth</artifactId> </dependency> Importing camel-mail-microsoft-oauth will automatically import camel-mail component. 88.2. Microsoft Exchange Online OAuth2 Mail Authenticator IMAP sample To use OAuth, an application must be registered with Azure Active Directory. Follow the instructions to register a new application. Procedure Enable the application to access Exchange mailboxes via client credentials flow. For more information, see Authenticate an IMAP, POP or SMTP connection using OAuth Once everything is set up, declare and register in the registry, an instance of org.apache.camel.component.mail.MicrosoftExchangeOnlineOAuth2MailAuthenticator . For Example, in a Spring Boot application: @BindToRegistry("auth") public MicrosoftExchangeOnlineOAuth2MailAuthenticator exchangeAuthenticator(){ return new MicrosoftExchangeOnlineOAuth2MailAuthenticator(tenantId, clientId, clientSecret, "jon@doe.com"); } Then reference it in the Camel URI as follows: from("imaps://outlook.office365.com:993" + "?authenticator=#auth" + "&mail.imaps.auth.mechanisms=XOAUTH2" + "&debugMode=true" + "&delete=false")

Commands:
<dependency> <groupId>org.apache.camel.springboot</groupId> <artifactId>camel-mail-microsoft-oauth</artifactId> </dependency>
@BindToRegistry("auth") public MicrosoftExchangeOnlineOAuth2MailAuthenticator exchangeAuthenticator(){ return new MicrosoftExchangeOnlineOAuth2MailAuthenticator(tenantId, clientId, clientSecret, "jon@doe.com"); }
from("imaps://outlook.office365.com:993" + "?authenticator=#auth" + "&mail.imaps.auth.mechanisms=XOAUTH2" + "&debugMode=true" + "&delete=false")
Chapter 3. Playing back recorded sessions There are two methods for replaying recorded sessions: the tlog-play tool the RHEL 8 web console, also referred to as Cockpit . 3.1. Playback with tlog-play You can use the tlog-play tool to play back session recordings in a terminal. The tlog-play tool is a playback program for terminal input and output recorded with the tlog-rec tool. It reproduces the recording of the terminal it is under, but cannot change its size. For this reason the playback terminal needs to match the recorded terminal size for proper playback. The tlog-play tool loads its parameters from the /etc/tlog/tlog-play.conf configuration file. You can override those parameters with command line options described in the tlog-play manual pages. 3.2. Playback with the web console The RHEL 8 web console has a whole interface for managing recorded sessions. You can choose the session you want to review directly from the Session Recording page, where the list of your recorded session is. Example 3.1. Example list of recorded sessions The web console player supports window resizing. 3.3. Playing back recorded sessions with tlog-play You can play back session recordings from exported log files or from the Systemd Journal. Playing back from a file You can play a session back from a file both during and after recording: Playing back from the Journal Generally, you can select Journal log entries for playback using Journal matches and timestamp limits, with the -M or --journal-match , -S or --journal-since , and -U or --journal-until options. In practice however, playback from Journal is usually done with a single match against the TLOG_REC Journal field. The TLOG_REC field contains a copy of the rec field from the logged JSON data, which is a host-unique ID of the recording. You can take the ID either from the TLOG_REC field value directly, or from the MESSAGE field from the JSON rec field. Both fields are part of log messages coming from the tlog-rec-session tool. Procedure You can play back the whole recording as follows: You can find further instructions and documentation in the tlog-play manual pages.

Commands:
tlog-play --reader=file --file-path=tlog.log
tlog-play -r journal -M TLOG_REC=<your-unique-host-id>