mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Introduction to AMQ Broker on OpenShift Container Platform Red Hat AMQ Broker 7.8 is available as a containerized image for use with OpenShift Container Platform (OCP) 3.11 and 4.5 and 4.6. AMQ Broker is based on Apache ActiveMQ Artemis. It provides a message broker that is JMS-compliant. After you have set up the initial broker pod, you can quickly deploy duplicates by using OpenShift Container Platform features. 1.1. Version compatibility and support For details about OpenShift Container Platform image version compatibility, see: OpenShift and Atomic Platform 3.x Tested Integrations OpenShift Container Platform 4.x Tested Integrations 1.2. Unsupported features Master-slave-based high availability High availability (HA) achieved by configuring master and slave pairs is not supported. Instead, when pods are scaled down, HA is provided in OpenShift by using the scaledown controller, which enables message migration. External Clients that connect to a cluster of brokers, either through the OpenShift proxy or by using bind ports, may need to be configured for HA accordingly. In a clustered scenario, a broker will inform certain clients of the addresses of all the broker's host and port information. Since these are only accessible internally, certain client features either will not work or will need to be disabled. Client Configuration Core JMS Client Because external Core Protocol JMS clients do not support HA or any type of failover, the connection factories must be configured with useTopologyForLoadBalancing=false . AMQP Clients AMQP clients do not support failover lists Durable subscriptions in a cluster When a durable subscription is created, this is represented as a durable queue on the broker to which a client has connected. When a cluster is running within OpenShift the client does not know on which broker the durable subscription queue has been created. If the subscription is durable and the client reconnects there is currently no method for the load balancer to reconnect it to the same node. When this happens, it is possible that the client will connect to a different broker and create a duplicate subscription queue. For this reason, using durable subscriptions with a cluster of brokers is not recommended.

Commands:
14.22.8. Listing Information about a Virtual Network Returns the list of active networks, if --all is specified this will also include defined but inactive networks, if --inactive is specified only the inactive ones will be listed. You may also want to filter the returned networks by --persistent to list the persitent ones, --transient to list the transient ones, --autostart to list the ones with autostart enabled, and --no-autostart to list the ones with autostart disabled. Note: When talking to older servers, this command is forced to use a series of API calls with an inherent race, where a pool might not be listed or might appear more than once if it changed state between calls while the list was being collected. Newer servers do not have this problem. To list the virtual networks, run:

Commands:
net-list [ --inactive | --all ] [ --persistent ] [< --transient >] [--autostart] [< --no-autostart >]
33.3. Boot Loader Options Figure 33.3. Boot Loader Options Please note that this screen will be disabled if you have specified a target architecture other than x86 / x86_64. GRUB is the default boot loader for Red Hat Enterprise Linux on x86 / x86_64 architectures. If you do not want to install a boot loader, select Do not install a boot loader . If you choose not to install a boot loader, make sure you create a boot diskette or have another way to boot your system, such as a third-party boot loader. You must choose where to install the boot loader (the Master Boot Record or the first sector of the /boot partition). Install the boot loader on the MBR if you plan to use it as your boot loader. To pass any special parameters to the kernel to be used when the system boots, enter them in the Kernel parameters text field. For example, if you have an IDE CD-ROM Writer, you can tell the kernel to use the SCSI emulation driver that must be loaded before using cdrecord by configuring hdd=ide-scsi as a kernel parameter (where hdd is the CD-ROM device). You can password protect the GRUB boot loader by configuring a GRUB password. Select Use GRUB password , and enter a password in the Password field. Type the same password in the Confirm Password text field. To save the password as an encrypted password in the file, select Encrypt GRUB password . If the encryption option is selected, when the file is saved, the plain text password that you typed is encrypted and written to the kickstart file. If the password you typed was already encrypted, uncheck the encryption option. Important It is highly recommended to set up a boot loader password on every machine. An unprotected boot loader can allow a potential attacker to modify the system's boot options and gain access to the system. See the chapter titled Workstation Security in the Red Hat Enterprise Linux Security Guide for more information on boot loader passwords and password security in general. If Upgrade an existing installation is selected on the Installation Method page, select Upgrade existing boot loader to upgrade the existing boot loader configuration, while preserving the old entries.

Commands:
19.4. Near Caches in a Clustered Environment Near caches are implemented using Hot Rod Remote Events, and utilize clustered listeners for receiving events from across the cluster. Clustered listeners are installed on a single node within the cluster, with the remaining nodes sending events to the node on which the listeners are installed. It is therefore possible for a node running the near cache-backing clustered listener to fail. In this situation, another node takes over the clustered listener. When the node running the clustered listener fails, a client failover event callback can be defined and invoked. For near caches, this callback and its implementation will clear the near cache, as during a failover events may be missed. Refer to Section 7.5, "Clustered Listeners" for more information. Report a bug

Commands:
Chapter 12. Clustered Samba Configuration As of the Red Hat Enterprise Linux 6.2 release, the Red Hat High Availability Add-On provides support for running Clustered Samba in an active/active configuration. This requires that you install and configure CTDB on all nodes in a cluster, which you use in conjunction with GFS2 clustered file systems. Note Red Hat Enterprise Linux 6 supports a maximum of four nodes running clustered Samba. This chapter describes the procedure for configuring CTDB by configuring an example system. For information on configuring GFS2 file systems, see Global File System 2 . For information on configuring logical volumes, see Logical Volume Manager Administration . Note Simultaneous access to the data in the Samba share from outside of Samba is not supported. 12.1. CTDB Overview CTDB is a cluster implementation of the TDB database used by Samba. To use CTDB, a clustered file system must be available and shared on all nodes in the cluster. CTDB provides clustered features on top of this clustered file system. As of the Red Hat Enterprise Linux 6.2 release, CTDB also runs a cluster stack in parallel to the one provided by Red Hat Enterprise Linux clustering. CTDB manages node membership, recovery/failover, IP relocation and Samba services.

Commands:
21.8. Loop Device Errors If file-based guest images are used you may have to increase the number of configured loop devices. The default configuration allows up to eight active loop devices. If more than eight file-based guests or loop devices are needed the number of loop devices configured can be adjusted in the /etc/modprobe.d/ directory. Add the following line: This example uses 64 but you can specify another number to set the maximum loop value. You may also have to implement loop device backed guests on your system. To use a loop device backed guests for a full virtualized system, use the phy: device or file: file commands.

Commands:
options loop max_loop=64
Chapter 27. Red Hat Decision Manager clusters By clustering two or more computers, you have the benefits of high availability, enhanced collaboration, and load balancing. High availability decreases the chance of data loss when a single computer fails. When a computer fails, another computer fills the gap by providing a copy of the data that was on the failed computer. When the failed computer comes online again, it resumes its place in the cluster. There are several ways that you can cluster Red Hat Decision Manager components. This document describes how to cluster the following scenarios: Chapter 28, Red Hat Process Automation Manager clusters in a development (authoring) environment Chapter 29, KIE Server clusters in a runtime environment

Commands:
3.6. Tapsets Tapsets are scripts that form a library of pre-written probes and functions to be used in SystemTap scripts. When a user runs a SystemTap script, SystemTap checks the script's probe events and handlers against the tapset library; SystemTap then loads the corresponding probes and functions before translating the script to C (see Section 3.1, "Architecture" for information on what transpires in a SystemTap session). Like SystemTap scripts, tapsets use the file name extension .stp . The standard library of tapsets is located in the /usr/share/systemtap/tapset/ directory by default. However, unlike SystemTap scripts, tapsets are not meant for direct execution; rather, they constitute the library from which other scripts can pull definitions. The tapset library is an abstraction layer designed to make it easier for users to define events and functions. Tapsets provide useful aliases for functions that users may want to specify as an event; knowing the proper alias to use is, for the most part, easier than remembering specific kernel functions that might vary between kernel versions. Several handlers and functions in Section 3.2.1, "Event" and SystemTap Functions are defined in tapsets. For example, thread_indent() is defined in indent.stp .

Commands:
Chapter 2. Installing CodeReady Workspaces on OpenShift 3 using the Operator Operators are a method of packaging, deploying, and managing a OpenShift application which also provide the following: Repeatability of installation and upgrade. Constant health checks of every system component. Over-the-air (OTA) updates for OpenShift components and ISV content. A place to encapsulate knowledge from field engineers and spread it to all users. This chapter describes how to install CodeReady Workspaces on OpenShift 3 using the CLI management tool and the Operator method. 2.1. Installing CodeReady Workspaces on OpenShift 3 using the Operator This section describes how to install CodeReady Workspaces on OpenShift 3 with the CLI management tool to install via the Operator with SSL (HTTPS) enabled. As of 2.1.1, SSL/TLS is enabled by default as it is required by the Che-Theia IDE. Prerequisites A running instance of OpenShift 3.11. Administrator rights on this OpenShift 3 instance. The oc OpenShift 3.11 CLI management tool is installed and configured. See Installing the OpenShift 3.11 CLI . To check the version of the oc tool, use the oc version command. The crwctl CLI management tool is installed. See Installing the crwctl CLI management tool . Procedure Log in to OpenShift. See Basic Setup and Login . Run the following command to create the CodeReady Workspaces instance: Note To create the CodeReady Workspaces instance on OpenShift clusters that have not been configured with a valid certificate for the routes, run the crwctl command with the --self-signed-cert flag. Verification steps The output of the command ends with: Navigate to the CodeReady Workspaces cluster instance: https://codeready-<openshift_deployment_name>.<domain_name> . The domain uses Let's Encrypt ACME certificates.

Commands:
oc login
crwctl server:start -n <openshift_namespace>
Command server:start has completed successfully.
Chapter 4. Project deployment options with Red Hat Process Automation Manager After you develop, test, and build your Red Hat Process Automation Manager project, you can deploy the project to begin using the business assets you have created. You can deploy a Red Hat Process Automation Manager project to a configured KIE Server, to an embedded Java application, or into a Red Hat OpenShift Container Platform environment for an enhanced containerized implementation. The following options are the main methods for Red Hat Process Automation Manager project deployment: Table 4.1. Project deployment options Deployment option Description Documentation Deployment to an OpenShift environment Red Hat OpenShift Container Platform combines Docker and Kubernetes and enables you to create and manage containers. You can install both Business Central and KIE Server on OpenShift. Red Hat Process Automation Manager provides templates that you can use to deploy a Red Hat Process Automation Manager authoring environment, managed server environment, immutable server environment, or trial environment on OpenShift. With OpenShift, components of Red Hat Process Automation Manager are deployed as separate OpenShift pods. You can scale each of the pods up and down individually, providing as few or as many containers as necessary for a particular component. You can use standard OpenShift methods to manage the pods and balance the load. Deploying an Red Hat Process Automation Manager environment on Red Hat OpenShift Container Platform 4 using Operators Deploying an Red Hat Process Automation Manager environment on Red Hat OpenShift Container Platform 3 using templates Deployment to KIE Server KIE Server is the server provided with Red Hat Process Automation Manager that runs the decision services, process applications, and other deployable assets from a packaged and deployed Red Hat Process Automation Manager project (KJAR file). These services are consumed at run time through an instantiated KIE container, or deployment unit . You can deploy and maintain deployment units in KIE Server using Business Central or using a headless Process Automation Manager controller with its associated REST API (considered a managed KIE Server instance). You can also deploy and maintain deployment units using the KIE Server REST API or Java client API from a standalone Maven project, an embedded Java application, or other custom environment (considered an unmanaged KIE Server instance). Packaging and deploying an Red Hat Process Automation Manager project Interacting with Red Hat Process Automation Manager using KIE APIs Managing and monitoring KIE Server Deployment to an embedded Java application If you want to deploy Red Hat Process Automation Manager projects to your own Java virtual machine (JVM) environment, microservice, or application server, you can bundle the application resources in the project WAR files to create a deployment unit similar to a KIE container. You can also use the core KIE APIs (not KIE Server APIs) to configure a KIE scanner to periodically update KIE containers. KIE Public API

Commands:
Chapter 5. Installing a three-node cluster on Nutanix In OpenShift Container Platform version 4.17, 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
22.16.15. Configuring the Time-to-Live for NTP Packets To specify that a particular time-to-live ( TTL ) value should be used in place of the default, add the following option to the end of a server or peer command: ttl value Specify the time-to-live value to be used in packets sent by broadcast servers and multicast NTP servers. Specify the maximum time-to-live value to use for the " expanding ring search " by a manycast client. The default value is 127 .

Commands:
A.2. Comparing Entries ldapcompare checks entries to see if the specified entry or entries contain an attribute of a specific value. For example, this checks to see if an entry has an sn value of Smith: The compare attribute can be specified in one of three ways: A single attribute:value statement passed in the command line directly A single attribute::base64value statement passed in the command line directly, for attributes like jpegPhoto or to verify certificates or CRLs An attribute:file statement that points to a file containing a list of comparison values for the attribute, and the script iterates through the list The compare operation itself has to be run against a specific entry or group of entries. A single entry DN can be passed through the command line, or a list of DNs to be compared can be given using the -f option. Example A.1. Comparing One Attribute Value to One Entry Both the attribute-value comparison and the DN are passed with the script. Example A.2. Comparing a List Attribute Values from a File First, create a file of possible sn values. Then, create a list of entries to compare the values to. Then run the script.

Commands:
ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:smith uid=bjensen,ou=people,dc=example,dc=com comparing type: "sn" value: "smith" in entry "uid=bjensen,ou=people,dc=example,dc=com" compare FALSE ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:smith uid=jsmith,ou=people,dc=example,dc=com comparing type: "sn" value: "smith" in entry "uid=jsmith,ou=people,dc=example,dc=com" compare TRUE
sn:Smith
jpegPhoto:dkdkPDKCDdko0eiofk==
postalCode:/tmp/codes.txt
ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:smith uid=jsmith,ou=people,dc=example,dc=com comparing type: "sn" value: "smith" in entry "uid=jsmith,ou=people,dc=example,dc=com" compare TRUE
jensen johnson johannson jackson jorgenson
uid=jen200,ou=people,dc=example,dc=com uid=dsj,ou=people,dc=example,dc=com uid=matthewjms,ou=people,dc=example,dc=com uid=john1234,ou=people,dc=example,dc=com uid=jack.son.1990,ou=people,dc=example,dc=com
ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:/tmp/surnames.txt -f /tmp/names.txt comparing type: "sn" value: "jensen" in entry "uid=jen200,ou=people,dc=example,dc=com" compare TRUE
Chapter 7. Installation and Booting rpm supports ordered installation based on package tags The OrderWithRequires feature has been added to the RPM Package Manager, which utilizes the new OrderWithRequires package tag. If a package specified in OrderWithRequires is present in a package transaction, it is installed before the package with the corresponding OrderWithRequires tag is installed. However, unlike the Requires package tag, OrderWithRequires does not generate additional dependencies, so if the package specified in the tag is not present in the transaction, it is not downloaded. Anaconda now displays a warning if LDL-formatted DASDs are detected during installation On IBM System z, DASDs with LDL (Linux Disk Layout) format are recognized by the kernel, but the installer does not support them. If one or more such DASDs are detected by Anaconda, it will display a warning about their unsupported status and offer to format them as CDL (Compatibility Disk Layout), which is a fully supported format type.

Commands:
Chapter 1. Activating Red Hat Ansible Automation Platform Red Hat Ansible Automation Platform uses available subscriptions or a subscription manifest to authorize the use of Ansible Automation Platform. To obtain a subscription, you can do either of the following: Use your Red Hat customer or Satellite credentials when you launch Ansible Automation Platform. Upload a subscriptions manifest file either using the Red Hat Ansible Automation Platform interface or manually in an Ansible playbook. To activate Ansible Automation Platform using credentials, see Activate with credentials . To activate Ansible Automation Platform with a manifest file, see Activate with a manifest file .

Commands:
Chapter 6. Login Modules for Jakarta Enterprise Beans and Remoting 6.1. Remoting Login Module Short name : Remoting Full name : org.jboss.as.security.remoting.RemotingLoginModule Parent : AbstractServer Login Module The Remoting login module allows remote Jakarta Enterprise Beans invocations, coming in over remoting, to perform a SASL-based authentication. This allows the remote user to establish their identity via SASL and have that identity be used for authentication and authorization when making that Jakarta Enterprise Beans invocation. Table 6.1. Remoting Login Module Options Option Type Default Description useClientCert boolean false If true , the login module will obtain the SSLSession of the connection and substitute the peer's X509Certificate in place of the password. 6.2. Client Login Module Short name : Client Full name : org.jboss.security.ClientLoginModule Client login module is an implementation of login module for use by JBoss EAP clients when establishing caller identity and credentials. This creates a new SecurityContext , assigns it a principal and a credential and sets the SecurityContext to the ThreadLocal security context. Client login module is the only supported mechanism for a client to establish the current thread's caller. Both standalone client applications, and server environments, acting as JBoss EAP Jakarta Enterprise Beans clients where the security environment has not been configured to use the JBoss EAP security subsystem transparently, must use Client login module. Warning This login module does not perform any authentication. It merely copies the login information provided to it into the server Jakarta Enterprise Beans invocation layer for subsequent authentication on the server. Within JBoss EAP, this is only supported for the purpose of switching a user's identity for in-JVM calls. This is NOT supported for remote clients to establish an identity. Table 6.2. Client Login Module Options Option Type Default Description multi-threaded true or false true Set to true if each thread has its own principal and credential storage. Set to false to indicate that all threads in the VM share the same identity and credential. password-stacking useFirstPass or false false Set to useFirstPass to indicate that this login module should look for information stored in the LoginContext to use as the identity. This option can be used when stacking other login modules with this one. restore-login-identity true or false false Set to true if the identity and credential seen at the start of the login() method should be restored after the logout() method is invoked.

Commands: