mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. Deploying clustered Redis on Red Hat Ansible Automation Platform Operator When you create an Ansible Automation Platform instance through the Ansible Automation Platform Operator, standalone Redis is assigned by default. To deploy clustered Redis, use the following procedure. For more information about Redis, refer to Caching and queueing system in the Planning your installation guide. Prerequisites You have installed an Ansible Automation Platform Operator deployment. Procedure Log in to Red Hat OpenShift Container Platform. Navigate to Operators Installed Operators . Select your Ansible Automation Platform Operator deployment. Select the Details tab. On the Ansible Automation Platform tile click Create instance . For existing instances, you can edit the YAML view by clicking the ... icon and then Edit AnsibleAutomationPlatform . Change the redis_mode value to "cluster". Click Reload , then Save . Click to expand Advanced configuration . For the Redis Mode list, select Cluster . Configure the rest of your instance as necessary, then click Create . Your instance will deploy with a cluster Redis with 6 Redis replicas as default.

Commands:
Chapter 11. Reinstalling a hyperconverged host Some configuration changes require a hyperconverged host to be reinstalled before the configuration change can take effect. Follow these steps to reinstall a hyperconverged host. Log in to the Administration Portal. Click Compute Hosts . Select the host and click Management > Maintenance > OK to place this host in Maintenance mode. Click Installation > Reinstall to open the Reinstall window. On the General tab, uncheck the Automatically Configure Host firewall checkbox. On the Hosted Engine tab, set the value of Choose hosted engine deployment action to Deploy . Click OK to reinstall the host.

Commands:
5.41. ctdb 5.41.1. RHBA-2012:0904 - ctdb bug fix update Updated ctdb packages that fix one bug are now available for Red Hat Enterprise Linux 6. The ctdb packages provide a clustered database based on Samba's Trivial Database (TDB) used to store temporary data. Bug Fix BZ# 794888 Prior to this update, the ctdb working directory, all subdirectories and the files within were created with incorrect SELinux contexts when the ctdb service was started. This update uses the post-install script to create the ctdb directory, and the command "/sbin/restorecon -R /var/ctdb" sets now the right SELinux context. All users of ctdb are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 4. Installing Red Hat build of OpenJDK with the MSI installer This procedure describes how to install Red Hat build of OpenJDK 21 for Microsoft Windows using the MSI-based installer. Procedure Download the MSI-based installer of Red Hat build of OpenJDK 21 for Microsoft Windows. Run the installer for Red Hat build of OpenJDK 21 for Microsoft Windows. Click on the welcome screen. Check I accept the terms in license agreement , then click . Click . Accept the defaults or review the optional properties . Click Install . Click Yes on the Do you want to allow this app to make changes on your device? . To verify the Red Hat build of OpenJDK 21 for Microsoft Windows is successfully installed, run java -version command in the command prompt.

Commands:
Chapter 3. Assigning automation hub administrator permissions Hub administrative users will need to be assigned the role of hubadmin in order to manage user permissions and groups. You can assign the role of hubadmin to a user through the Ansible Automation Platform Central Authentication client. Prerequisites A user storage provider (e.g., LDAP) has been added to your central authentication Procedure Navigate to the ansible-automation-platform realm on your SSO client. From the navigation panel, select User Access Users . Select a user from the list by clicking their ID. Click the Role Mappings tab. From the Client Roles list, select automation-hub . Click hubadmin from the Available Roles field, then click Add selected > . The user is now a hubadmin . Repeat steps 3-6 to assign any additional users the hubadmin role.

Commands:
Chapter 24. Limiting SCHED_OTHER task migration You can limit the tasks that SCHED_OTHER migrates to other CPUs using the sched_nr_migrate variable. Prerequisites You have administrator privileges. 24.1. Task migration If a SCHED_OTHER task spawns a large number of other tasks, they will all run on the same CPU. The migration task or softirq will try to balance these tasks so they can run on idle CPUs. The sched_nr_migrate option can be adjusted to specify the number of tasks that will move at a time. Because real-time tasks have a different way to migrate, they are not directly affected by this. However, when softirq moves the tasks, it locks the run queue spinlock, thus disabling interrupts. If there are a large number of tasks that need to be moved, it occurs while interrupts are disabled, so no timer events or wakeups will be allowed to happen simultaneously. This can cause severe latencies for real-time tasks when sched_nr_migrate is set to a large value. 24.2. Limiting SCHED_OTHER task migration using the sched_nr_migrate variable Increasing the sched_nr_migrate variable provides high performance from SCHED_OTHER threads that spawn many tasks at the expense of real-time latency. For low real-time task latency at the expense of SCHED_OTHER task performance, the value must be lowered. The default value is 8 . Procedure To adjust the value of the sched_nr_migrate variable, echo the value directly to /proc/sys/kernel/sched_nr_migrate : Verification View the contents of /proc/sys/kernel/sched_nr_migrate :

Commands:
echo 2 > /proc/sys/kernel/sched_nr_migrate
cat > /proc/sys/kernel/sched_nr_migrate 2
Chapter 11. Finding and cleaning stale subvolumes (Technology Preview) Sometimes stale subvolumes don't have a respective k8s reference attached. These subvolumes are of no use and can be deleted. You can find and delete stale subvolumes using the ODF CLI tool. Important Deleting stale subvolumes using the ODF CLI tool is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information, see Technology Preview Features Support Scope . Prerequisites Download the ODF CLI tool from the customer portal . Procedure Find the stale subvolumes by using the --stale flag with the subvolumes command: Example output: Delete the stale subvolumes: Replace <subvolumes> with a comma separated list of subvolumes from the output of the first command. The subvolumes must be of the same filesystem and subvolumegroup. Replace <filesystem> and <subvolumegroup> with the filesystem and subvolumegroup from the output of the first command. For example: Example output:

Commands:
odf subvolume ls --stale
Filesystem Subvolume Subvolumegroup State ocs-storagecluster-cephfilesystem csi-vol-427774b4-340b-11ed-8d66-0242ac110004 csi stale ocs-storagecluster-cephfilesystem csi-vol-427774b4-340b-11ed-8d66-0242ac110005 csi stale
odf subvolume delete <subvolumes> <filesystem> <subvolumegroup>
odf subvolume delete csi-vol-427774b4-340b-11ed-8d66-0242ac110004,csi-vol-427774b4-340b-11ed-8d66-0242ac110005 ocs-storagecluster csi
Info: subvolume csi-vol-427774b4-340b-11ed-8d66-0242ac110004 deleted Info: subvolume csi-vol-427774b4-340b-11ed-8d66-0242ac110004 deleted
Chapter 1. Support policy for Cryostat Red Hat supports a major version of Cryostat for a minimum of 6 months. Red Hat bases this figure on the time that the product gets released on the Red Hat Customer Portal. You can install and deploy Cryostat on Red Hat OpenShift Container Platform 4.11 or a later version that runs on an x86_64 or ARM64 architecture. Additional resources For more information about the Cryostat life cycle policy, see Red Hat build of Cryostat on the Red Hat OpenShift Container Platform Life Cycle Policy web page.

Commands:
4.29. VMware over SOAP API Table 4.30, "VMware Fencing (SOAP Interface) (Red Hat Enterprise Linux 6.2 and later)" lists the fence device parameters used by fence_vmware_soap , the fence agent for VMware over SOAP API. Table 4.30. VMware Fencing (SOAP Interface) (Red Hat Enterprise Linux 6.2 and later) luci Field cluster.conf Attribute Description Name name Name of the virtual machine fencing device. IP Address or Hostname ipaddr The IP address or host name assigned to the device. IP Port (optional) ipport The TCP port to use for connection with the device. The default port is 80, or 443 if Use SSL is selected. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. VM name port Name of virtual machine in inventory path format (for example, /datacenter/vm/Discovered_virtual_machine/myMachine). VM UUID uuid The UUID of the virtual machine to fence. Delay (optional) delay The number of seconds to wait before fencing is started. The default value is 0. Use SSL ssl Use SSL connections to communicate with the device. Figure 4.22, "VMware over SOAP Fencing" shows the configuration screen for adding a VMware over SOAP fence device Figure 4.22. VMware over SOAP Fencing The following command creates a fence device instance for a VMware over SOAP fence device: The following is the cluster.conf entry for the fence_vmware_soap device:

Commands:
ccs -f cluster.conf --addfencedev vmwaresoaptest1 agent=fence_vmware_soap login=root passwd=password123 power_wait=60 separator=,
<fencedevices> <fencedevice agent="fence_vmware_soap" ipaddr="192.168.0.1" login="root" name="vmwaresoaptest1" passwd="password123" power_wait="60" separator="."/> </fencedevices>
probe::linuxmib.TCPMemoryPressures Name probe::linuxmib.TCPMemoryPressures - Count of times memory pressure was used Synopsis linuxmib.TCPMemoryPressures Values sk Pointer to the struct sock being acted on op Value to be added to the counter (default value of 1) Description The packet pointed to by skb is filtered by the function linuxmib_filter_key . If the packet passes the filter is is counted in the global TCPMemoryPressures (equivalent to SNMP's MIB LINUX_MIB_TCPMEMORYPRESSURES)

Commands:
Chapter 64. System and Subscription Management System upgrade may cause Yum to install unneeded 32-bit packages if rdma-core is installed In Red Hat Enterprise Linux 7.4, the rdma-core.noarch packages are obsoleted by rdma-core.i686 and rdma-core.x86_64 . During a system upgrade, Yum replaces the original package with both of the new packages, and installs any required dependencies. This means that the 32-bit package, as well a potentially large amount of its 32-bit dependencies, is installed by default, even if not required. To work around this problem, you can either use the yum update command with the --exclude=\*.i686 option, or you can use yum remove rdma-core.i686 after the upgrade to remove the 32-bit package. (BZ#1458338)

Commands:
8.2.2. Backup Software: Buy Versus Build In order to perform backups, it is first necessary to have the proper software. This software must not only be able to perform the basic task of making copies of bits onto backup media, it must also interface cleanly with your organization's personnel and business needs. Some of the features to consider when reviewing backup software include: Schedules backups to run at the proper time Manages the location, rotation, and usage of backup media Works with operators (and/or robotic media changers) to ensure that the proper media is available Assists operators in locating the media containing a specific backup of a given file As you can see, a real-world backup solution entails much more than just scribbling bits onto your backup media. Most system administrators at this point look at one of two solutions: Purchase a commercially-developed solution Create an in-house developed backup system from scratch (possibly integrating one or more open source technologies) Each approach has its good and bad points. Given the complexity of the task, an in-house solution is not likely to handle some aspects (such as media management, or have comprehensive documentation and technical support) very well. However, for some organizations, this might not be a shortcoming. A commercially-developed solution is more likely to be highly functional, but may also be overly-complex for the organization's present needs. That said, the complexity might make it possible to stick with one solution even as the organization grows. As you can see, there is no clear-cut method for deciding on a backup system. The only guidance that can be offered is to ask you to consider these points: Changing backup software is difficult; once implemented, you will be using the backup software for a long time. After all, you will have long-term archive backups that you must be able to read. Changing backup software means you must either keep the original software around (to access the archive backups), or you must convert your archive backups to be compatible with the new software. Depending on the backup software, the effort involved in converting archive backups may be as straightforward (though time-consuming) as running the backups through an already-existing conversion program, or it may require reverse-engineering the backup format and writing custom software to perform the task. The software must be 100% reliable -- it must back up what it is supposed to, when it is supposed to. When the time comes to restore any data -- whether a single file or an entire file system -- the backup software must be 100% reliable.

Commands:
1.2. Virtualization Solutions Red Hat offers the following major virtualization solutions, each with a different user focus and features: Red Hat Enterprise Linux The ability to create, run, and manage virtual machines, as well as a number of virtualization tools and features are included in Red Hat Enterprise Linux 7. This solution supports a limited number of running guests per host, as well as a limited range of guest types. As such, virtualization on Red Hat Enterprise Linux can be useful for example to developers who require testing in multiple environments, or to small businesses running several servers that do not have strict uptime requirements or service-level agreements (SLAs). Important This guide provides information about virtualization on Red Hat Enterprise Linux and does not go into detail about other virtualization solutions. Red Hat Virtualization Red Hat Virtualization (RHV) is based on the Kernel-based Virtual Machine ( KVM ) technology like virtualization on Red Hat Enterprise Linux is, but offers an enhanced array of features. Designed for enterprise-class scalability and performance, it enables management of your entire virtual infrastructure, including hosts, virtual machines, networks, storage, and users from a centralized graphical interface. Note For more information about the differences between virtualization in Red Hat Enterprise Linux and Red Hat Virtualization, see the Red Hat Customer Portal. Red Hat Virtualization can be used by enterprises running larger deployments or mission-critical applications. Examples of large deployments suited to Red Hat Virtualization include databases, trading platforms, and messaging systems that must run continuously without any downtime. Note For more information about Red Hat Virtualization, or to download a fully supported 60-day evaluation version, see http://www.redhat.com/en/technologies/virtualization/enterprise-virtualization . Alternatively, see the Red Hat Virtualization documentation suite . Red Hat OpenStack Platform Red Hat OpenStack Platform offers an integrated foundation to create, deploy, and scale a secure and reliable public or private OpenStack cloud. Note For more information about Red Hat OpenStack Platform, or to download a 60-day evaluation version, see https://www.redhat.com/en/technologies/linux-platforms/openstack-platform . Alternatively, see the Red Hat OpenStack Platform documentation suite.

Commands:
14.5.7. Modifying the Link State of a Domain's Virtual Interface The following command can either configure a specified interface as up or down: Using this modifies the status of the specified interface for the specified domain. Note that if you only want the persistent configuration of the domain to be modified, you need to use the --config option. It should also be noted that for compatibility reasons, --persistent is an alias of --config . The "interface device" can be the interface's target name or the MAC address.

Commands:
domif-setlink [domain] [interface-device] [state] { --config }
domif-setlink rhel6 eth0 up
33.10. Pre-Installation Script Figure 33.13. Pre-Installation Script You can add commands to run on the system immediately after the kickstart file has been parsed and before the installation begins. If you have configured the network in the kickstart file, the network is enabled before this section is processed. To include a pre-installation script, type it in the text area. Important The version of anaconda in releases of Red Hat Enterprise Linux included a version of busybox that provided shell commands in the pre-installation and post-installation environments. The version of anaconda in Red Hat Enterprise Linux 6 no longer includes busybox , and uses GNU bash commands instead. Refer to Appendix G, Alternatives to busybox commands for more information. To specify a scripting language to use to execute the script, select the Use an interpreter option and enter the interpreter in the text box beside it. For example, /usr/bin/python2.6 can be specified for a Python script. This option corresponds to using %pre --interpreter /usr/bin/python2.6 in your kickstart file. Only the most commonly used commands are available in the pre-installation environment. See Section 32.6, "Pre-installation Script" for a complete list. Important Do not include the %pre command. It is added for you. Note The pre-installation script is run after the source media is mounted and stage 2 of the bootloader has been loaded. For this reason it is not possible to change the source media in the pre-installation script.

Commands:
Chapter 10. Kafka Streams API overview The Kafka Streams API allows applications to receive data from one or more input streams, execute complex operations like mapping, filtering or joining, and write the results into one or more output streams. It is part of the kafka-streams JAR package that is available in the Red Hat Maven repository. 10.1. Adding the Kafka Streams API as a dependency to your Maven project This procedure shows you how to add the AMQ Streams Java clients as a dependency to your Maven project. Prerequisites A Maven project with an existing pom.xml . Procedure Add the Red Hat Maven repository to the <repositories> section of your pom.xml file. Add kafka-streams to the <dependencies> section of your pom.xml file. Build your Maven project.

Commands:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <repositories> <repository> <id>redhat-maven</id> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <!-- ... --> </project>
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <dependencies> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-streams</artifactId> <version>3.1.0.redhat-00004</version> </dependency> </dependencies> <!-- ... --> </project>
Chapter 2. Additional requirements for single node deployments Red Hat Hyperconverged Infrastructure for Virtualization is supported for deployment on a single node provided that all Support Requirements are met, with the following additions and exceptions. A single node deployment requires a physical machine with: 1 Network Interface Controller at least 12 cores at least 64GB RAM Single node deployments cannot be scaled , and are not highly available. This deployment type is lower cost, but removes the option of availability.

Commands:
Workloads APIs OpenShift Container Platform 4.13 Reference guide for workloads APIs Red Hat OpenShift Documentation Team

Commands:
"postCommit": { "script": "rake test --verbose", }
The above is a convenient form which is equivalent to:
"postCommit": { "command": ["/bin/sh", "-ic"], "args": ["rake test --verbose"] }
"postCommit": { "commit": ["rake", "test", "--verbose"] }
Command overrides the image entrypoint in the exec form, as documented in Docker: https://docs.docker.com/engine/reference/builder/#entrypoint.
"postCommit": { "args": ["rake", "test", "--verbose"] }
This form is only useful if the image entrypoint can handle arguments.
"postCommit": { "script": "rake test USD1", "args": ["--verbose"] }
This form is useful if you need to pass arguments that would otherwise be hard to quote properly in the shell script. In the script, USD0 will be "/bin/sh" and USD1, USD2, etc, are the positional arguments from Args.
"postCommit": { "command": ["rake", "test"], "args": ["--verbose"] }
This form is equivalent to appending the arguments to the Command slice.
"postCommit": { "script": "rake test --verbose", }
The above is a convenient form which is equivalent to:
"postCommit": { "command": ["/bin/sh", "-ic"], "args": ["rake test --verbose"] }
"postCommit": { "commit": ["rake", "test", "--verbose"] }
Command overrides the image entrypoint in the exec form, as documented in Docker: https://docs.docker.com/engine/reference/builder/#entrypoint.
"postCommit": { "args": ["rake", "test", "--verbose"] }
This form is only useful if the image entrypoint can handle arguments.
"postCommit": { "script": "rake test USD1", "args": ["--verbose"] }
This form is useful if you need to pass arguments that would otherwise be hard to quote properly in the shell script. In the script, USD0 will be "/bin/sh" and USD1, USD2, etc, are the positional arguments from Args.
"postCommit": { "command": ["rake", "test"], "args": ["--verbose"] }
This form is equivalent to appending the arguments to the Command slice.
IP: An IP address allocated to the pod. Routable at least within the cluster.