mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 13. High availability and clusters The following chapter contains the most notable changes to high availability and clusters between RHEL 8 and RHEL 9. 13.1. Notable changes to high availability and clusters pcs commands that support the clufter tool have been removed The pcs commands that support the clufter tool for analyzing cluster configuration formats have been removed. The following commands have been removed: pcs config import-cman for importing CMAN / RHEL6 HA cluster configuration pcs config export for exporting cluster configuration to a list of pcs commands which recreate the same cluster pcs suppport for OCF Resource Agent API 1.1 standard The pcs command-line interface now supports OCF 1.1 resource and STONITH agents. As part of the implementation of this support, any agent's metadata must comply with the OCF schema, whether the agent is an OCF 1.0 or OCF 1.1 agent. If an agent's metadata does not comply with the OCF schema, pcs considers the agent invalid and will not create or update a resource of the agent unless the --force option is specified. The pcsd Web UI and pcs commands for listing agents now omit agents with invalid metadata from the listing. New pcs parsing requires meta keyword when specifying clone meta attributes To ensure consistency in the pcs command format, configuring clone meta attributes with the pcs resource clone , pcs resource promotable , and pcs resource create commands without specifying the meta keyword is now deprecated. Previously, the meta keyword was ignored in the pcs resource clone and pcs resource promotable commands. In the pcs resource create command, however, the meta attributes specified after the meta keyword when it followed the clone keyword were assigned to the resource rather than to the clone. With this updated parsing algorithm, meta attributes specified after the meta keyword when it follows the clone keyword are assigned to the clone. To maintain compatibility with existing scripts which rely on the older format, you must specify the --future command option to enable this new argument processing when creating a cloned resource with the pcs resource create command. The following command now creates a resource with the meta attribute mv=v1 and a clone with the meta attribute mv=v2 : pcs resource create dummy1 ocf:pacemaker:Dummy meta m1=v1 clone meta m2=v2 --future

Commands:
Preface Important Deploying OpenShift Data Foundation using Red Hat OpenShift Service on AWS with hosted control planes is a technology preview feature. Technology Preview features provide early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. However, these features are not fully supported under Red Hat Service Level Agreements, may not be functionally complete, and are not intended for production use. As Red Hat considers making future iterations of Technology Preview features generally available, we will attempt to resolve any issues that customers experience when using these features. See Technology Preview Features Support Scope for more information.

Commands:
2.2.3.5. Use Kerberos Authentication One of the issues to consider when NIS is used for authentication is that whenever a user logs into a machine, a password hash from the /etc/shadow map is sent over the network. If an intruder gains access to a NIS domain and sniffs network traffic, they can collect user names and password hashes. With enough time, a password cracking program can guess weak passwords, and an attacker can gain access to a valid account on the network. Since Kerberos uses secret-key cryptography, no password hashes are ever sent over the network, making the system far more secure. Refer to Managing Single Sign-On and Smart Cards for more information about Kerberos.

Commands:
C.4. Example User Interface Plug-in Deployment Follow these instructions to create a user interface plug-in that runs a Hello World! program when you sign in to the Red Hat Virtualization Manager Administration Portal. Deploying a Hello World! Plug-in Create a plug-in descriptor by creating the following file in the Manager at /usr/share/ovirt-engine/ui-plugins/helloWorld.json : { "name": "HelloWorld", "url": "/ovirt-engine/webadmin/plugin/HelloWorld/start.html", "resourcePath": "hello-files" } Create the plug-in host page by creating the following file in the Manager at /usr/share/ovirt-engine/ui-plugins/hello-files/start.html : <!DOCTYPE html><html><head> <script> var api = parent.pluginApi('HelloWorld'); api.register({ UiInit: function() { window.alert('Hello world'); } }); api.ready(); </script> </head><body></body></html> If you have successfully implemented the Hello World! plug-in, you will see this screen when you sign in to the Administration Portal: Figure C.1. A Successful Implementation of the Hello World! Plug-in

Commands:
name: HelloWorld
url: /ovirt-engine/webadmin/plugin/HelloWorld/start.html
resourcePath: hello-files
<!DOCTYPE html><html><head> <script> var api = parent.pluginApi('HelloWorld'); api.register({ UiInit: function() { window.alert('Hello world'); } }); api.ready(); </script> </head><body></body></html>
Chapter 12. Manage secure signatures with sigstore You can use the sigstore project with OpenShift Container Platform to improve supply chain security. 12.1. About the sigstore project The sigstore project enables developers to sign-off on what they build and administrators to verify signatures and monitor workflows at scale. With the sigstore project, signatures can be stored in the same registry as the build images. A second server is not needed. The identity piece of a signature is tied to the OpenID Connect (OIDC) identity through the Fulcio certificate authority, which simplifies the signature process by allowing key-less signing. Additionally, sigstore includes Rekor, which records signature metadata to an immutable, tamper-resistant ledger.

Commands:
1.4. Processing 1.4.1. Join Algorithms Nested loop does the most obvious processing - for every row in the outer source, it compares with every row in the inner source. Nested loop is only used when the join criteria has no equi-join predicates. Merge join first sorts the input sources on the joined columns. You can then walk through each side in parallel (effectively one pass through each sorted source) and when you have a match, emit a row. In general, merge join is on the order of n+m rather than n*m in nested loop. Merge join is the default algorithm. Using costing information the engine may also delay the decision to perform a full sort merge join. Based upon the actual row counts involved, the engine can choose to build an index of the smaller side (which will perform similarly to a hash join) or to only partially sort the larger side of the relation. Joins involving equi-join predicates are also eligible to be made into dependent joins (see Section 13.7.3, "Dependent Joins" ). 1.4.2. Sort-Based Algorithms Sorting is used as the basis of the Sort (ORDER BY), Grouping (GROUP BY), and DupRemoval (SELECT DISTINCT) operations. The sort algorithm is a multi-pass merge-sort that does not ever require all of the result set to be in memory, yet uses the maximal amount of memory allowed by the buffer manager. It consists of two phases. The first phase ("sort") will take an unsorted input stream and produce one or more sorted input streams. Each pass reads as much of the unsorted stream as possible, sorts it, and writes it back out as a new stream. Since the stream size may be bigger than that of the memory, it may be written out as many sorted streams. The second phase ("merge") consists of a set of phases that grab the batch from as many sorted input streams as will fit in memory. It then repeatedly grabs the tuple in sorted order from each stream and outputs merged sorted batches to a new sorted stream. At completion of the pass, all input streams are dropped. Hence, each pass reduces the number of sorted streams. The last stream remaining is the final output.

Commands:
Chapter 10. Volume size overrides You can specify the desired size of storage resources provisioned for managed components. The default size for Clair and the PostgreSQL databases is 50Gi . You can now choose a large enough capacity upfront, either for performance reasons or in the case where your storage backend does not have resize capability. In the following example, the volume size for the Clair and the Quay PostgreSQL databases has been set to 70Gi : apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: quay-example namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: clair managed: true overrides: volumeSize: 70Gi - kind: postgres managed: true overrides: volumeSize: 70Gi - kind: clairpostgres managed: true Note The volume size of the clairpostgres component cannot be overridden. This is a known issue and will be fixed in a future version of Red Hat Quay.( PROJQUAY-4301 )

Commands:
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: quay-example namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: clair managed: true overrides: volumeSize: 70Gi - kind: postgres managed: true overrides: volumeSize: 70Gi - kind: clairpostgres managed: true
18.6. Malicious Software and Spoofed IP Addresses More elaborate rules can be created that control access to specific subnets, or even specific nodes, within a LAN. You can also restrict certain dubious applications or programs such as trojans, worms, and other client/server viruses from contacting their server. For example, some trojans scan networks for services on ports from 31337 to 31340 (called the elite ports in cracking terminology). Since there are no legitimate services that communicate via these non-standard ports, blocking them can effectively diminish the chances that potentially infected nodes on your network independently communicate with their remote master servers. The following rules drop all TCP traffic that attempts to use port 31337: You can also block outside connections that attempt to spoof private IP address ranges to infiltrate your LAN. For example, if your LAN uses the 192.168.1.0/24 range, you can design a rule that instructs the Internet-facing network device (for example, eth0) to drop any packets to that device with an address in your LAN IP range. Because it is recommended to reject forwarded packets as a default policy, any other spoofed IP address to the external-facing device (eth0) is rejected automatically. Note There is a distinction between the DROP and REJECT targets when dealing with appended rules. The REJECT target denies access and returns a connection refused error to users who attempt to connect to the service. The DROP target, as the name implies, drops the packet without any warning. Administrators can use their own discretion when using these targets. However, to avoid user confusion and attempts to continue connecting, the REJECT target is recommended.

Commands:
iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
function::ansi_set_color Name function::ansi_set_color - Set the ansi Select Graphic Rendition mode. Synopsis Arguments fg Foreground color to set. General Syntax ansi_set_color(fh:long) Description Sends ansi code for Select Graphic Rendition mode for the given forground color. Black (30), Blue (34), Green (32), Cyan (36), Red (31), Purple (35), Brown (33), Light Gray (37).

Commands:
function ansi_set_color(fg:long)
Chapter 47. Closing cases A case instance can be completed when there are no more activities to be performed and the business goal is achieved, or it can be closed prematurely. Usually the case owner closes the case when all work is completed and the case goals have been met. When you close a case, consider adding a comment about why the case instance is being closed. A closed case can be reopened later with the same case ID if required. When a case is reopened, stages that were active when the case was closed will be active when the case is reopened. You can close case instances remotely using KIE Server REST API requests or directly in the Showcase application. 47.1. Closing a case using the KIE Server REST API You can use a REST API request to close a case instance. Red Hat Process Automation Manager includes the Swagger client, which includes endpoints and documentation for REST API requests. Alternatively, you can use the same endpoints to make API calls using your preferred client or Curl. Prerequisites A case instance has been started using Showcase. You are able to authenticate API requests as a user with the admin role. Procedure Open the Swagger REST API client in a web browser: http://localhost:8080/kie-server/docs Under Case Instances :: Case Management , open the POST request with the following endpoint: /server/containers/{id}/cases/instances/{caseId} Click Try it out and fill in the required parameters: Table 47.1. Parameters Name Description id itorders caseId IT-0000000001 Optional: Include a comment to be included in the case file. To leave a comment, type it into the body text field as a String . Click Execute to close the case. To confirm the case is closed, open the Showcase application and change the case list status to Closed . 47.2. Closing a case in the Showcase application A case instance is complete when no more activities need to be performed and the business goal has been achieved. After a case is complete, you can close the case to indicate that the case is complete and that no further work is required. When you close a case, consider adding a specific comment about why you are closing the case. If needed, you can reopen the case later with the same case ID. You can use the Showcase application to close a case instance at any time. From Showcase, you can easily view the details of the case or leave a comment before closing it. Prerequisites You are logged in to the Showcase application and are the owner or administrator for a case instance that you want to close. Procedure In the Showcase application, locate the case instance you want to close from the list of case instances. To close the case without viewing the details first, click Close . To close the case from the case details page, click the case in the list to open it. From the case overview page you can add comments to the case and verify that you are closing the correct case based on the case information. Click Close to close the case. Click Back to Case List in the upper-left corner of the page to return to the Showcase case list view. Click the drop-down list to Status and select Canceled to view the list of closed and canceled cases.

Commands:
Chapter 1. Overview of HawtIO HawtIO is a diagnostic Console for the Red Hat build of Apache Camel and Red Hat build of AMQ. It is a pluggable Web diagnostic console built with modern Web technologies such as React and PatternFly . HawtIO provides a central interface to examine and manage the details of one or more deployed HawtIO-enabled containers. HawtIO is available when you install HawtIO standalone or use HawtIO on OpenShift. The integrations that you can view and manage in HawtIO depend on the plugins that are running. You can monitor HawtIO and system resources, perform updates, and start or stop services. The pluggable architecture is based on Webpack Module Federation and is highly extensible; you can dynamically extend HawtIO with your plugins or automatically discover plugins inside the JVM. HawtIO has built-in plugins already to make it highly useful out of the box for your JVM application. The plugins include Apache Camel, Connect, JMX, Logs, Runtime, Quartz, and Spring Boot. HawtIO is primarily designed to be used with Camel Quarkus and Camel Spring Boot. It's also a tool for managing microservice applications. HawtIO is cloud-native; it's ready to go over the cloud! You can deploy it to Kubernetes and OpenShift with the HawtIO Operator . Among the benefits of HawtIO are: Runtime management of JVM via JMX, especially that of Camel applications and AMQ broker, with specialized views Visualization and debugging/tracing of Camel routes Simple managing and monitoring of application metrics The following diagram depicts the architectural overview of HawtIO: HawtIO Standalone HawtIO On OpenShift

Commands:
Chapter 5. Starting and Stopping Red Hat JBoss Data Virtualization 5.1. Starting Red Hat JBoss Data Virtualization To run Red Hat JBoss Data Virtualization, you must first start the JBoss EAP server. To start the JBoss EAP server, follow the instructions below for your operating system: For Red Hat Enterprise Linux, open a command line window and enter this command from your EAP_HOME directory (the directory in which EAP in installed): For Microsoft Windows, open a command line window and enter these commands: To ensure that the server has started correctly and to verify that there have been no errors, check the server log: EAP_HOME/standalone/log/server.log Note You can also verify the execution was error-free by opening the Management Console in a web browser and logging in using the username and password of a registered JBoss EAP Management User. The console's address is http://localhost:9990/console/ (For more information about using the Management Console see the Red Hat JBoss Enterprise Application Platform Administration and Configuration Guide .) Note For more advanced starting options, see the Red Hat JBoss Enterprise Application Platform Administration and Configuration Guide . 5.2. Stopping Red Hat JBoss Data Virtualization To stop Red Hat JBoss Data Virtualization, halt the JBoss EAP Server. Do this by pressing Ctrl+C in the terminal in which EAP is running.

Commands:
./bin/standalone.sh
chdir EAP_HOME/bin standalone.bat
Chapter 10. IO Subsystem Tuning The io subsystem defines XNIO workers and buffer pools that are used by other JBoss EAP subsystems, such as Undertow and Remoting. 10.1. Configuring Workers You can create multiple separate workers that each have their own performance configuration and which handle different I/O tasks. For example, you could create one worker to handle HTTP I/O, and another worker to handle Jakarta Enterprise Beans I/O, and then separately configure the attributes of each worker for specific load requirements. See the IO Subsystem Attributes appendix for the list of configurable worker attributes. Worker attributes that significantly affect performance include io-threads which sets the total number of I/O threads that a worker can use, and task-max-threads which sets the maximum number of threads that can be used for a particular task. The defaults for these two attributes are calculated based on the server's CPU count. See the JBoss EAP Configuration Guide for instructions on how to create and configure workers . 10.1.1. Monitoring Worker Statistics You can view a worker's runtime statistics using the management CLI. This exposes worker statistics such as connection count, thread count, and queue size. The following command displays runtime statistics for the default worker: Note The number of core threads, which is tracked by the core-pool-size statistic, is currently always set to the same value as the maximum number of threads, which is tracked by the max-pool-size statistic. 10.2. Configuring Buffer Pools Note IO buffer pools are deprecated, but they are still set as the default in the current release. For more information about configuring Undertow byte buffer pools, see the Configuring Byte Buffer Pools section of the Configuration Guide for JBoss EAP. A buffer pool in the io subsystem is a pooled NIO buffer instance that is used specifically for I/O operations. Like workers , you can create separate buffer pools which can be dedicated to handle specific I/O tasks. See the IO Subsystem Attributes appendix for the list of configurable buffer pool attributes. The main buffer pool attribute that significantly affects performance is buffer-size . The default is calculated based on the RAM resources of your system, and is sufficient in most cases. If you are configuring this attribute manually, an ideal size for most servers is 16KB. See the JBoss EAP Configuration Guide for instructions on how to create and configure buffer pools .

Commands:
/subsystem=io/worker= default :read-resource(include-runtime=true,recursive=true)
32.2.2. Adding a User To add a user to the system: Issue the useradd command to create a locked user account: Unlock the account by issuing the passwd command to assign a password and set password aging guidelines: Command line options for useradd are detailed in Table 32.1, " useradd Command Line Options" . Table 32.1. useradd Command Line Options Option Description -c ' <comment> ' <comment> can be replaced with any string. This option is generally used to specify the full name of a user. -d <home-dir> Home directory to be used instead of default /home/ <username> / -e <date> Date for the account to be disabled in the format YYYY-MM-DD -f <days> Number of days after the password expires until the account is disabled. If 0 is specified, the account is disabled immediately after the password expires. If -1 is specified, the account is not be disabled after the password expires. -g <group-name> Group name or group number for the user's default group. The group must exist prior to being specified here. -G <group-list> List of additional (other than default) group names or group numbers, separated by commas, of which the user is a member. The groups must exist prior to being specified here. -m Create the home directory if it does not exist. -M Do not create the home directory. -n Do not create a user private group for the user. -r Create a system account with a UID less than 500 and without a home directory -p <password> The password encrypted with crypt -s User's login shell, which defaults to /bin/bash -u <uid> User ID for the user, which must be unique and greater than 499

Commands:
useradd <username>
passwd <username>
Chapter 4. Deploying the configured back ends To deploy the configured back ends, complete the following steps: Procedure Log in as the stack user. Run the following command to deploy the custom back end configuration: Important If you passed any extra environment files when you created the overcloud, pass them again here using the -e option to avoid making undesired changes to the overcloud. For more information, see Modifying the overcloud environment in the Director Installation and Usage guide.

Commands:
openstack overcloud deploy --templates -e /home/stack/templates/custom-env.yaml