mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. Chaining LDAP controls LDAP operations can contains some data (named control and specified in the ldap protocol) that change their behavior. You can specify which LDAP controls to forward to the remote server. 11.1. About chaining LDAP controls The database link forwards requests containing the following controls to the remote server for chaining LDAP controls: The Virtual List View (VLV) control provides lists of certain entries. The Server-side sorting control categorizes entries according to their attribute values, usually by using a specific matching rule. The Dereferencing control pulls specified attribute information from the referenced entry and returns this information with the rest of the search results. The Managed DSA controls returns smart referrals as entries, rather than following these referrals. Therefore, a smart referral itself can be changed or deleted. The Loop detection control tracks how many times a server chains with another server. When the count reaches the configured number, Loop detection detects a loop and notifies the client application. Note Database links cannot support Server-side sorting and VLV controls when a client application makes a request to multiple databases. The following are some of the LDAP controls that are allowed to chain and their object identifiers (OID): Control Name OID Virtual list view (VLV) 2.16.840.1.113730.3.4.9 Server-side sorting 1.2.840.113556.1.4.473 Managed DSA 2.16.840.1.113730.3.4.2 Loop detection 1.3.6.1.4.1.1466.29539.12 Dereferencing searches 1.3.6.1.4.1.4203.666.5.16 11.2. Chaining LDAP controls using the command line You can chain LDAP controls by using dsconf chaining config-set --add-control in the command line. Procedure Chain LDAP controls: Add the object identifier (OID) of the custom control if clients of Directory Server create their own controls and chain there operations to remote servers. 11.3. Chaining LDAP controls using the web console You can chain LDAP controls by using the web console. Prerequisites You have opened the Directory Server user interface in the web console and selected the instance. Procedure Open the Database menu. Select the Chaining Configuration entry. Click Add button below the Forwarded LDAP Controls field. Select the LDAP control and click Add & Save New Controls button. Add the object identifier (OID) of the custom control if clients of Directory Server create their own controls and chain there operations to remote servers. Click Save button. Verification Click the Database menu and ensure that the selected LDAP control is chained.

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com chaining \ config-set --add-control="2.16.840.1.113730.3.4.9"
3.6. Image Builder blueprint format Image Builder blueprints are stored as plain text in the Tom's Obvious, Minimal Language (TOML) format. The elements of a typical blueprint file include: The blueprint metadata Replace BLUEPRINT-NAME and LONG FORM DESCRIPTION TEXT with a name and description for your blueprint. Replace VERSION with a version number according to the Semantic Versioning scheme. This part is present only once for the whole blueprint file. The entry modules describe the package names and matching version glob to be installed into the image and the entry group describe a group of packages to be installed into the image. If you do not add these items, the blueprint indentify them as an empyt lists. Packages included in the image Replace package-name with name of the package, such as httpd , gdb-doc , or coreutils . Replace package-version with a version to use. This field supports dnf version specifications: For a specific version, use the exact version number such as 7.30 . For latest available version, use the asterisk * . For a latest minor version, use format such as 7.* . Repeat this block for every package to be included.

Commands:
name = " BLUEPRINT-NAME " description = " LONGER BLUEPRINT DESCRIPTION " version = " VERSION " modules = [] groups = []
[[packages]] name = " package-name " version = " package-version "
Chapter 2. New features and enhancements Red Hat JBoss Web Server 6.0 Service Pack 4 includes the following new features and enhancements. 2.1. Java 21 support JBoss Web Server 6.0 is now certified for use with Red Hat build of OpenJDK 21 and Oracle JDK 21. Note Java 21 is now fully tested and supported for both RPM package and archive file distributions of JBoss Web Server 6.0. This service pack release is not available in archive file format, but the existing JBoss Web Server 6.0 archive file distributions are fully compatible with Java 21 support. 2.2. JWS for OpenShift image for OpenJDK 21 This release introduces support for importing JWS for OpenShift images that are compatible with OpenJDK 21. In this release, you can import a jboss-webserver60-openjdk21-tomcat10-openshift-ubi8 image. Note For more information about importing the jboss-webserver60-openjdk21-tomcat10-openshift-ubi8 image, see the RHEA-2024:6900 advisory. Because this Service Pack 4 release is not available in archive file format, the latest jboss-webserver60-openjdk21-tomcat10-openshift-ubi8 image is based on the 6.0.3 archive file distribution.

Commands:
3.16. Starting a Virtual Machine with Specific Boot Devices and Boot Order This Ruby example starts a virtual machine specifying the boot devices and boot order. # Find the root of the tree of services: system_service = connection.system_service # Find the virtual machine: vms_service = system_service.vms_service vm = vms_service.list(search: 'name=myvm').first # Find the service that manages the virtual machine: vm_service = vms_service.vm_service(vm.id) # Start the virtual machine explicitly indicating the boot devices and order: vm_service.start( vm: { os: { boot: { devices: [ OvirtSDK4::BootDevice::NETWORK, OvirtSDK4::BootDevice::CDROM ] } } } ) # Wait until the virtual machine is up: loop do sleep(5) vm = vm_service.get break if vm.status == OvirtSDK4::VmStatus::UP end For more information, see http://www.rubydoc.info/gems/ovirt-engine-sdk/OvirtSDK4/BootDevice .

Commands:
Find the root of the tree of services: system_service = connection.system_service Find the virtual machine: vms_service = system_service.vms_service vm = vms_service.list(search: 'name=myvm').first Find the service that manages the virtual machine: vm_service = vms_service.vm_service(vm.id) Start the virtual machine explicitly indicating the boot devices and order: vm_service.start( vm: { os: { boot: { devices: [ OvirtSDK4::BootDevice::NETWORK, OvirtSDK4::BootDevice::CDROM ] } } } ) Wait until the virtual machine is up: loop do sleep(5) vm = vm_service.get break if vm.status == OvirtSDK4::VmStatus::UP end
Chapter 2. Enabling accelerators Before you can use an accelerator in OpenShift AI, you must install the relevant software components. The installation process varies based on the accelerator type. Prerequisites You have logged in to your OpenShift cluster. You have the cluster-admin role in your OpenShift cluster. You have installed an accelerator and confirmed that it is detected in your environment. Procedure Follow the appropriate documentation to enable your accelerator: NVIDIA GPUs : See Enabling NVIDIA GPUs . Intel Gaudi AI accelerators : See Enabling Intel Gaudi AI accelerators . AMD GPUs : See Enabling AMD GPUs . After installing your accelerator, create an accelerator profile as described in: Working with accelerator profiles . Verification From the Administrator perspective, go to the Operators Installed Operators page. Confirm that the following Operators appear: The Operator for your accelerator Node Feature Discovery (NFD) Kernel Module Management (KMM) The accelerator is correctly detected a few minutes after full installation of the Node Feature Discovery (NFD) and the relevant accelerator Operator. The OpenShift command line interface (CLI) displays the appropriate output for the GPU worker node. For example, here is output confirming that an NVIDIA GPU is detected:

Commands:
Expected output when the accelerator is detected correctly 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
Chapter 8. Granting and Restricting Access to SSSD Containers Using HBAC Rules For the Identity Management domain, each SSSD container represents itself as a different host, and administrators can set up host-based access control (HBAC) rules to allow or restrict access to individual containers separately. For details about configuring HBAC rules in Identity Management, see Configuring Host-Based Access Control in the Linux Domain Identity, Authentication, and Policy Guide

Commands:
6.5. SSD Optimization Using the btrfs file system can optimize SSD. There are two ways this can be done. The first way is mkfs.btrfs turns off metadata duplication on a single device when /sys/block/ device /queue/rotational is zero for the single specified device. This is equivalent to specifying -m single on the command line. It can be overridden and duplicate metadata forced by providing the -m dup option. Duplication is not required due to SSD firmware potentially losing both copies. This wastes space and is a performance cost. The second way is through a group of SSD mount options: ssd , nossd , and ssd_spread . The ssd option does several things: It allows larger metadata cluster allocation. It allocates data more sequentially where possible. It disables btree leaf rewriting to match key and block order. It commits log fragments without batching multiple processes. Note The ssd mount option only enables the ssd option. Use the nossd option to disable it. Some SSDs perform best when reusing block numbers often, while others perform much better when clustering strictly allocates big chunks of unused space. By default, mount -o ssd will find groupings of blocks where there are several free blocks that might have allocated blocks mixed in. The command mount -o ssd_spread ensures there are no allocated blocks mixed in. This improves performance on lower end SSDs. Note The ssd_spread option enables both the ssd and the ssd_spread options. Use the nossd to disable both these options. The ssd_spread option is never automatically set if none of the ssd options are provided and any of the devices are non-rotational. These options will all need to be tested with your specific build to see if their use improves or reduces performance, as each combination of SSD firmware and application loads are different.

Commands:
8.3. Moving Resources Due to Connectivity Changes Setting up the cluster to move resources when external connectivity is lost is a two step process. Add a ping resource to the cluster. The ping resource uses the system utility of the same name to test if a list of machines (specified by DNS host name or IPv4/IPv6 address) are reachable and uses the results to maintain a node attribute called pingd . Configure a location constraint for the resource that will move the resource to a different node when connectivity is lost. Table 6.1, "Resource Properties" describes the properties you can set for a ping resource. Table 8.1. Properties of a ping resources Field Description dampen The time to wait (dampening) for further changes to occur. This prevents a resource from bouncing around the cluster when cluster nodes notice the loss of connectivity at slightly different times. multiplier The number of connected ping nodes gets multiplied by this value to get a score. Useful when there are multiple ping nodes configured. host_list The machines to contact in order to determine the current connectivity status. Allowed values include resolvable DNS host names, IPv4 and IPv6 addresses. The entries in the host list are space separated. The following example command creates a ping resource that verifies connectivity to gateway.example.com . In practice, you would verify connectivity to your network gateway/router. You configure the ping resource as a clone so that the resource will run on all cluster nodes. The following example configures a location constraint rule for the existing resource named Webserver . This will cause the Webserver resource to move to a host that is able to ping gateway.example.com if the host that it is currently running on cannot ping gateway.example.com .

Commands:
pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=gateway.example.com clone
pcs constraint location Webserver rule score=-INFINITY pingd lt 1 or not_defined pingd
macro::json_output_array_numeric_value Name macro::json_output_array_numeric_value - Output a numeric value for metric in an array. Synopsis Arguments array_name The name of the array. array_index The array index (as a string) indicating where to store the numeric value. metric_name The name of the numeric metric. value The numeric value to output. Description The json_output_array_numeric_value macro is designed to be called from the 'json_data' probe in the user's script to output a metric's numeric value that is in an array. This metric should have been added with json_add_array_numeric_metric .

Commands:
@json_output_array_numeric_value(array_name,array_index,metric_name,value)
Chapter 5. Installing a three-node cluster on Nutanix In OpenShift Container Platform version 4.15, you can install a three-node cluster on Nutanix. 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. 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 # ... 5.2. steps Installing a cluster on Nutanix

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
B.44. libuser B.44.1. RHSA-2011:0170 - Moderate: libuser security update Updated libuser packages that fix one security issue are now available for Red Hat Enterprise Linux 4, 5, and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The libuser library implements a standardized interface for manipulating and administering user and group accounts. Sample applications that are modeled after applications from the shadow password suite (shadow-utils) are included in these packages. CVE-2011-0002 It was discovered that libuser did not set the password entry correctly when creating LDAP (Lightweight Directory Access Protocol) users. If an administrator did not assign a password to an LDAP based user account, either at account creation with luseradd, or with lpasswd after account creation, an attacker could use this flaw to log into that account with a default password string that should have been rejected. Note Note that LDAP administrators that have used libuser tools to add users should check existing user accounts for plain text passwords, and reset them as necessary. Users of libuser should upgrade to these updated packages, which contain a backported patch to correct this issue.

Commands:
A.4. Notes for Administrators Many system customization files can include network interface names, and thus will require updates if moving a system from the old convention to the new convention. If you use the new naming convention, you will also need to update network interface names in areas such as custom iptables rules, scripts altering irqbalance, and other similar configuration files. Also, enabling this change for installation will require modification to existing kickstart files that use device names via the ksdevice parameter; these kickstart files will need to be updated to use the network device's MAC address or the network device's new name. Red Hat strongly recommends that you consider this feature to be an install-time choice; enabling or disabling the feature post-install, while technically possible, can be complicated and is not recommended. For those system administrators who want to do so, on a system that meets the minimum requirements, remove the /etc/udev/rules.d/70-persistent-net.rules file and the HWADDR lines from all /etc/sysconfig/network-scripts/ifcfg-* files. In addition, rename those ifcfg-* files to use this new naming convention. The new names will be in effect after reboot. Remember to update any custom scripts, iptables rules, and service configuration files that might include network interface names.

Commands:
Chapter 4. Launching a non-clustered JBoss EAP instance This chapter lists the steps to launch a non-clustered instance of JBoss EAP on a Red Hat Amazon Machine Image (AMI) created through a private AMI or public Marketplace listing. Prerequisites A suitable Red Hat AMI. See Supported Red Hat AMIs for more information. A pre-configured Security Group that allows incoming requests on at least ports 22, 8080, and 9990. Note You can connect to an EC2 instance through ssh as the ec2-user user. If you need administrative privileges, you can change to root user later. For example, Procedure Launch the Red Hat AMI instance. A non-clustered instance of JBoss EAP has been configured and launched on a Red Hat AMI. Note For complex configuration, you can either use the standalone.conf file in the JBoss EAP bin directory: /opt/rh/eap8/root/usr/share/wildfly/bin/ , or you can start the JBoss EAP service and configure the server using CLI. The script can be found in the bin directory. Then, reload the configuration. You must regularly run the yum -y update to apply security fixes and enhancements. Start JBoss EAP using the following command: Stop JBoss EAP using the following command: Note If you want to bind JBoss EAP to a different IP address, add the following line in the /etc/opt/rh/eap8/wildfly/eap8-standalone.conf file on RHEL 9. The internal IP address is translated into a public IP address by EC2.

Commands:
ssh -l ec2-user USD{INSTANCE_PUBLIC_IP} sudo su -
systemctl start eap8-standalone
systemctl stop eap8-standalone
WILDFLY_BIND=USDYOUR_PRIVATE_IP_ADDRESS
Chapter 62. BrokerCapacityOverride schema reference Used in: BrokerCapacity Property Property type Description brokers integer array List of Kafka brokers (broker identifiers). cpu string Broker capacity for CPU resource in cores or millicores. For example, 1, 1.500, 1500m. For more information on valid CPU resource units see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu . inboundNetwork string Broker capacity for inbound network throughput in bytes per second. Use an integer value with standard OpenShift byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s. outboundNetwork string Broker capacity for outbound network throughput in bytes per second. Use an integer value with standard OpenShift byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s.

Commands:
Chapter 18. Compiler and Tools System Information Gatherer and Reporter (SIGAR) The System Information Gatherer and Reporter (SIGAR) is a library and command-line tool for accessing operating system and hardware level information across multiple platforms and programming languages. In Red Hat Enterprise Linux 6.4 and later, SIGAR is considered a Technology Preview package. Package: sigar-1.6.5-0.4.git58097d9

Commands:
Chapter 2. OpenShift Data Foundation upgrade channels and releases In OpenShift Container Platform 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster upgrades. By controlling the pace of upgrades, these upgrade channels allow you to choose an upgrade strategy. As OpenShift Data Foundation gets deployed as an operator in OpenShift Container Platform, it follows the same strategy to control the pace of upgrades by shipping the fixes in multiple channels. Upgrade channels are tied to a minor version of OpenShift Data Foundation. For example, OpenShift Data Foundation 4.16 upgrade channels recommend upgrades within 4.16. Upgrades to future releases is not recommended. This strategy ensures that administrators can explicitly decide to upgrade to the minor version of OpenShift Data Foundation. Upgrade channels control only release selection and do not impact the version of the cluster that you install; the odf-operator decides the version of OpenShift Data Foundation to be installed. By default, it always installs the latest OpenShift Data Foundation release maintaining the compatibility with OpenShift Container Platform. So, on OpenShift Container Platform 4.16, OpenShift Data Foundation 4.16 will be the latest version which can be installed. OpenShift Data Foundation upgrades are tied to the OpenShift Container Platform upgrade to ensure that compatibility and interoperability are maintained with the OpenShift Container Platform. For OpenShift Data Foundation 4.16, OpenShift Container Platform 4.16 and 4.17 (when generally available) are supported. OpenShift Container Platform 4.17 is supported to maintain forward compatibility of OpenShift Data Foundation with OpenShift Container Platform. Keep the OpenShift Data Foundation version the same as OpenShift Container Platform in order to get the benefit of all the features and enhancements in that release. Important Due to fundamental Kubernetes design, all OpenShift Container Platform updates between minor versions must be serialized. You must update from OpenShift Container Platform 4.14 to 4.15 and then to 4.16. You cannot update from OpenShift Container Platform 4.14 to 4.16 directly. For more information, see Preparing to perform an EUS-to-EUS update of the Updating clusters guide in OpenShift Container Platform documentation. OpenShift Data Foundation 4.16 offers the following upgrade channel: stable-4.16 stable-4.15 stable-4.16 channel Once a new version is Generally Available, the stable channel corresponding to the minor version gets updated with the new image which can be used to upgrade. You can use the stable-4.16 channel to upgrade from OpenShift Data Foundation 4.15 and upgrades within 4.16. stable-4.15 You can use the stable-4.15 channel to upgrade from OpenShift Data Foundation 4.14 and upgrades within 4.15.

Commands:
Part II. Manually installing Red Hat Enterprise Linux Setting up a machine for installing Red Hat Enterprise Linux (RHEL) involves several key steps, from booting the installation media to configuring system options. After the installation ISO is booted, you can modify boot settings and monitor installation processes through various consoles and logs. By customizing the system during installation, you ensure that it is tailored to specific needs, and the initial setup process finalizes the configuration for first-time use.

Commands: