mtpti5iD/redhat-docs_dataset huggingface dataset:
20.5. Bug Fixes kdump no longer hangs due to the attempts to read the memory from on-board devices On the little-endian variants of IBM Power Systems hardware, the kdump mechanism became unresponsive because the kernel attempted to read the memory from on-board devices such as the GPU, and include it as a part of the vmcore . This update fixes kexec-tools to skip the on-board devices when attempting to read the memory during kdump . As a result, kdump now works correctly, the vmcore is saved to disk and the operating system reboots as expected. (BZ#1478049)

Commands:
6.7. Viewing Red Hat Satellite Errata for a Virtual Machine Errata for each virtual machine can be viewed after the Red Hat Virtualization virtual machine has been configured to receive errata information from the Red Hat Satellite server. For more information on configuring a virtual machine to display available errata see Configuring Satellite Errata Viewing Red Hat Satellite Errata Click Compute Virtual Machines . Click the virtual machine's name to go to the details view. Click Errata .

Commands:
31.2. Display Hardware Settings When the X Configuration Tool is started, it probes the monitor and video card. If the hardware is probed properly, the information for it is shown on the Hardware tab as shown in Figure 31.2, "Display Hardware Settings" . Figure 31.2. Display Hardware Settings To change the monitor type or any of its settings, click the corresponding Configure button. To change the video card type or any of its settings, click the Configure button beside its settings.

Commands:
Chapter 35. Storage mpathpersist no longer fails when opening too many files Previously, the mpathpersist utility sometimes overstepped the limit on open files when scanning a large number of devices. As a consequence, mpathpersist terminated unexpectedly. With this update, mpathpersist now checks the max_fds configuration value and correctly sets the maximum number of open files. As a result, mpathpersist no longer fails when opening too many files. (BZ#1610263) The multipathd readsector0 checker now returns the correct result Previously, in some cases the multipathd daemon was incorrectly calculating the I/O size to use with the readsector0 checker, causing it to do a 0 size read. This could cause the multipathd readsector0 checker to return the wrong result. It is also possible that some SCSI devices do not treat a 0 size read command as valid. With this fix, multipathd now uses the correct size for the readsector0 checker. (BZ# 1584228 ) DM Multipath is much less likely to output an incorrect timeout error Previously, Device Mapper Multipath (DM Multipath) printed an error message after reconfiguring devices for more than 10 seconds. The error was displayed even if the reconfigure was progressing successfully. As a consequence, it sometimes seemed that the reconfigure failed when reconfiguring a large number of devices. With this update, the timeout limit has been increased from 10 to 60 seconds, and DM Multipath is now much less likely to print incorrect timeout errors when reconfiguring a large number of devices. (BZ# 1544958 ) multipath now correctly prints the sysfs state of paths Previously, the multipath -l command did not print the sysfs state of paths because the multipath utility did not correctly set path information. With this update, the problem has been fixed, and multipath now prints the sysfs state of paths correctly. (BZ#1526876) multipathd can now correctly set APTPL when registering keys on path devices Previously, the multipathd service did not track which devices registered their persistent reservation keys with the Activate Persist Through Power Loss (APTPL) option. As a consequence, registrations always lost the APTPL setting. With this update, the problem has been fixed: If you set the reservation_key option to a file in the multipath.conf configuration file, multipathd now keeps the APTPL setting automatically. If you set reservation_key to a specific key, you can now add the :aptpl string at the end of the key in reservation_key , which enables APTPL for it. Set this to match the APTPL setting used when registering the key. (BZ# 1498724 )

Commands:
Chapter 66. Test template for DMN-based test scenarios Business Central automatically generates the template for every DMN-based test scenario asset and it contains all the specified inputs and decisions of the related DMN model. For each input node in the DMN model, a GIVEN column is added, whereas each decision node is represented by an EXPECT column. You can modify the default template at any time as per your needs. Also, to test only a specific part of the whole DMN model, its possible to remove the generated columns as well as move decision nodes from the EXPECT to the GIVEN section. 66.1. Creating a test scenario template for DMN-based test scenarios Create a test scenario template for DMN-based scenarios by following the procedure below to validate your DMN models. Procedure In Business Central, go to Menu Design Projects and click the project that you want to create the test scenario for. Click Add Asset Test Scenario . Enter a Test Scenario name and select the appropriate Package . Select DMN as the Source type . Select an existing DMN asset using the Choose DMN asset option. Click Ok to create and open the test scenario in the test scenarios designer. The template is automatically generated and you can modify it as per your needs. To define a java method to a property cell during test scenario execution: Click an instance header cell or property header cell. Select the data object field from the Test Tools tab. Click Insert Data Object . Use an expression to define a java method for test scenario execution. To add more properties to the data object, right-click the property header cell and select Insert column right or Insert column left as required. Use the contextual menu to add or remove columns and rows as needed. For more details about the expression syntax in DMN-based scenarios, see Section 70.2, "Expression syntax in DMN-based test scenarios" .

Commands:
Installing on OCI OpenShift Container Platform 4.16 Installing OpenShift Container Platform on Oracle Cloud Infrastructure Red Hat OpenShift Documentation Team

Commands:
cat ~/.ssh/id_rsa.put
Error: 400-InvalidParameter, DNS Label oci-demo does not follow Oracle requirements Suggestion: Please update the parameter(s) in the Terraform config as per error message DNS Label oci-demo does not follow Oracle requirements Documentation: https://registry.terraform.io/providers/oracle/oci/latest/docs/resources/core_vcn
./openshift-install version
./openshift-install 4.16.0 built from commit ae7977b7d1ca908674a0d45c5c243c766fa4b2ca release image registry.ci.openshift.org/origin/release:4.16ocp-release@sha256:0da6316466d60a3a4535d5fed3589feb0391989982fba59d47d4c729912d6363 release architecture amd64
install-config.yaml apiVersion: v1 baseDomain: <base_domain> 1 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 network type: OVNKubernetes machineNetwork: - cidr: <ip_address_from_cidr> 2 serviceNetwork: - 172.30.0.0/16 compute: - architecture: amd64 3 hyperthreading: Enabled name: worker replicas: 0 controlPlane: architecture: amd64 4 hyperthreading: Enabled name: master replicas: 3 platform: external: platformName: oci 5 cloudControllerManager: External sshKey: <public_ssh_key> 6 pullSecret: '<pull_secret>' 7
./openshift-install agent create image --log-level debug
apiVersion: v1alpha1 metadata: name: <cluster_name> 1 namespace: <cluster_namespace> 2 rendezvousIP: <ip_address_from_CIDR> 3 bootArtifactsBaseURL: <server_URL> 4
./openshift-install agent wait-for install-complete --log-level debug
export KUBECONFIG=~/auth/kubeconfig
oc get nodes -A
NAME STATUS ROLES AGE VERSION main-0.private.agenttest.oraclevcn.com Ready control-plane, master 7m v1.27.4+6eeca63 main-1.private.agenttest.oraclevcn.com Ready control-plane, master 15m v1.27.4+d7fa83f main-2.private.agenttest.oraclevcn.com Ready control-plane, master 15m v1.27.4+d7fa83f
oc get co
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.16.0-0 True False False 6m18s baremetal 4.16.0-0 True False False 2m42s network 4.16.0-0 True True False 5m58s Progressing: ... ...
Chapter 1. Getting started with functions Function lifecycle management includes creating and deploying a function, after which it can be invoked. You can do all of these operations on OpenShift Serverless using the kn func tool. 1.1. Prerequisites To enable the use of OpenShift Serverless Functions on your cluster, you must complete the following steps: The OpenShift Serverless Operator and Knative Serving are installed on your cluster. Note Functions are deployed as a Knative service. If you want to use event-driven architecture with your functions, you must also install Knative Eventing. You have the oc CLI installed. You have the Knative ( kn ) CLI installed. Installing the Knative CLI enables the use of kn func commands which you can use to create and manage functions. You have installed Docker Container Engine or Podman version 3.4.7 or higher. You have access to an available image registry, such as the OpenShift Container Registry. If you are using Quay.io as the image registry, you must ensure that either the repository is not private, or that you have followed the OpenShift Container Platform documentation on Allowing pods to reference images from other secured registries . If you are using the OpenShift Container Registry, a cluster administrator must expose the registry . 1.2. Creating, deploying, and invoking a function On OpenShift Serverless, you can use the kn func to create, deploy, and invoke a function. Procedure Create a function project: USD kn func create -l <runtime> -t <template> <path> Example command USD kn func create -l typescript -t cloudevents examplefunc Example output Created typescript function in /home/user/demo/examplefunc Navigate to the function project directory: Example command USD cd examplefunc Build and run the function locally: Example command USD kn func run Deploy the function to your cluster: USD kn func deploy Example output Function deployed at: http://func.example.com Invoke the function: USD kn func invoke This invokes either a locally or remotely running function. If both are running, the local one is invoked. 1.3. Additional resources for OpenShift Container Platform Exposing a default registry manually Marketplace page for the Intellij Knative plugin Marketplace page for the Visual Studio Code Knative plugin Creating applications using the Developer perspective 1.4. steps See Connecting an event source to a function

Commands:
kn func create -l <runtime> -t <template> <path>
kn func create -l typescript -t cloudevents examplefunc
Created typescript function in /home/user/demo/examplefunc
cd examplefunc
kn func run
kn func deploy
Function deployed at: http://func.example.com
kn func invoke
16.2. KDE Red Hat Enterprise Linux 7 features KDE Plasma Workspaces version 4.10 and the latest version of KDE Platform and Applications. To learn more about the release, consult http://www.kde.org/announcements/4.10/ . KScreen Configuration of multiple displays is improved with KScreen , a new screen management application for KDE. KScreen provides a new user interface for monitor configuration and automatic saving and restoring of profiles for connected monitors. For detailed information about KScreen, see http://community.kde.org/Solid/Projects/ScreenManagement .

Commands:
Chapter 1. Introducing .NET 9.0 .NET is a general-purpose development platform featuring automatic memory management and modern programming languages. Using .NET, you can build high-quality applications efficiently. .NET is available on Red Hat Enterprise Linux (RHEL) and OpenShift Container Platform through certified containers. .NET offers the following features: The ability to follow a microservices-based approach, where some components are built with .NET and others with Java, but all can run on a common, supported platform on RHEL and OpenShift Container Platform. The capacity to more easily develop new .NET workloads on Microsoft Windows. You can deploy and run your applications on either RHEL or Windows Server. A heterogeneous data center, where the underlying infrastructure is capable of running .NET applications without having to rely solely on Windows Server.

Commands:
Chapter 16. Configuring Message Expiry Sent messages can be set to expire on the server if they are not delivered to a consumer after a specified amount of time. These expired messages can later be consumed for further inspection. Set Message Expiry Using the Core API Using the core API, you can set an expiration time on a message using the setExpiration method. // The message will expire 5 seconds from now message.setExpiration(System.currentTimeMillis() + 5000); Set Message Expiry Using Jakarta Messaging You can set the time to live for the Jakarta Messaging MessageProducer to use when sending messages. You specify this value, in milliseconds, using the setTimeToLive method. // Messages sent by this producer will be retained for 5 seconds before expiring producer.setTimeToLive(5000); You can also specify the message expiry on a per-message basis by setting the time to live on the producer's send method. // The last parameter of the send method is the time to live, in milliseconds producer.send(message, DeliveryMode.PERSISTENT, 0, 5000) Expired messages that are consumed from an expiry address have the following properties. _AMQ_ORIG_ADDRESS A String property containing the original address of the expired message. _AMQ_ACTUAL_EXPIRY A Long property containing the actual expiration time of the expired message. 16.1. Expiry Address You can specify where to send expired messages by setting an expiry address. If a message expires and no expiry address is specified, the message is removed from the queue and dropped. You can set an expiry-address for an address-setting using the management CLI. In the below example, expired messages in the jms.queue.exampleQueue queue will be sent to the jms.queue.expiryQueue expiry address. 16.2. Expiry Reaper Thread A reaper thread periodically inspects the queues to check whether messages have expired. You can set the scan period and thread priority for the reaper thread using the management CLI. Set the scan period for the expiry reaper thread, which is how often, in milliseconds, the queues will be scanned to detect expired messages. The default is 30000 . You can set this to -1 to disable the reaper thread. Set the thread priority for the expiry reaper thread. Possible values are from 0 to 9 , with 9 being the highest priority. The default is 3 .

Commands:
// The message will expire 5 seconds from now message.setExpiration(System.currentTimeMillis() + 5000);
// Messages sent by this producer will be retained for 5 seconds before expiring producer.setTimeToLive(5000);
// The last parameter of the send method is the time to live, in milliseconds producer.send(message, DeliveryMode.PERSISTENT, 0, 5000)
/subsystem=messaging-activemq/server=default/address-setting=jms.queue.exampleQueue:write-attribute(name=expiry-address,value=jms.queue.expiryQueue)
/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-scan-period,value=30000)
/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-thread-priority,value=3)
5.7. Clustering corosync component The redundant ring feature of corosync is not fully supported in combination with InfiniBand or Distributed Lock Manager (DLM). A double ring failure can cause both rings to break at the same time on different nodes. In addition, DLM is not functional if ring0 is down. selinux-policy component The fence-sanlock agent does not support SELinux in Enforcing mode at the moment. lvm2 component, BZ# 814779 Clustered environment is not supported by lvmetad at the moment. If global/use_lvmetad=1 is used together with global/locking_type=3 configuration setting (clustered locking), the use_lvmetad setting is automatically overriden to 0 and lvmetad is not used in this case at all. Also, the following warning message is displayed: luci component, BZ# 615898 luci will not function with Red Hat Enterprise Linux 5 clusters unless each cluster node has ricci version 0.12.2-14.

Commands:
WARNING: configuration setting use_lvmetad overriden to 0 due to locking_type 3. Clustered environment not supported by lvmetad yet.
Chapter 6. Installing and preparing the Operators You install the Red Hat OpenStack Services on OpenShift (RHOSO) OpenStack Operator ( openstack-operator ) and create the RHOSO control plane on an operational Red Hat OpenShift Container Platform (RHOCP) cluster. You install the OpenStack Operator by using the RHOCP web console. You perform the control plane installation tasks and all data plane creation tasks on a workstation that has access to the RHOCP cluster. 6.1. Prerequisites An operational RHOCP cluster, version 4.16. For the RHOCP system requirements, see Red Hat OpenShift Container Platform cluster requirements in Planning your deployment . The oc command line tool is installed on your workstation. You are logged in to the RHOCP cluster as a user with cluster-admin privileges. 6.2. Installing the OpenStack Operator You use OperatorHub on the Red Hat OpenShift Container Platform (RHOCP) web console to install the OpenStack Operator ( openstack-operator ) on your RHOCP cluster. Procedure Log in to the RHOCP web console as a user with cluster-admin permissions. Select Operators OperatorHub . In the Filter by keyword field, type OpenStack . Click the OpenStack Operator tile with the Red Hat source label. Read the information about the Operator and click Install . On the Install Operator page, select "Operator recommended Namespace: openstack-operators" from the Installed Namespace list. Click Install to make the Operator available to the openstack-operators namespace. The Operators are deployed and ready when the Status of the OpenStack Operator is Succeeded .

Commands:
Chapter 15. Administering the Self-Hosted Engine 15.1. Maintaining the Self-Hosted Engine Self-hosted Engine Maintenance Modes The maintenance modes enable you to start, stop, and modify the Manager virtual machine without interference from the high-availability agents, and to restart and modify the self-hosted engine nodes in the environment without interfering with the Manager. There are three maintenance modes that can be enforced: global - All high-availability agents in the cluster are disabled from monitoring the state of the Manager virtual machine. The global maintenance mode must be applied for any setup or upgrade operations that require the ovirt-engine service to be stopped, such as upgrading to a later version of Red Hat Virtualization. local - The high-availability agent on the node issuing the command is disabled from monitoring the state of the Manager virtual machine. The node is exempt from hosting the Manager virtual machine while in local maintenance mode; if hosting the Manager virtual machine when placed into this mode, the Manager will migrate to another node, provided there is one available. The local maintenance mode is recommended when applying system changes or updates to a self-hosted engine node. none - Disables maintenance mode, ensuring that the high-availability agents are operating. Setting Local Maintenance Stop the high-availability agent on a single self-hosted engine node. Setting the local maintenance mode from the Administration Portal Put a self-hosted engine node into local maintenance mode: In the Administration Portal, click Compute Hosts and select a self-hosted engine node. Click Management Maintenance . Local maintenance mode is automatically triggered for that node. After you have completed any maintenance tasks, disable the maintenance mode: In the Administration Portal, click Compute Hosts and select the self-hosted engine node. Click Management Activate . Setting the local maintenance mode from the command line Log in to a self-hosted engine node and put it into local maintenance mode: After you have completed any maintenance tasks, disable the maintenance mode: Setting Global Maintenance Stop the high-availability agents on all self-hosted engine nodes in the cluster. Setting the global maintenance mode from the Administration Portal Put all of the self-hosted engine nodes into global maintenance mode: In the Administration Portal, click Compute Hosts and select any self-hosted engine node. Click More Actions ( ), then click Enable Global HA Maintenance . After you have completed any maintenance tasks, disable the maintenance mode: In the Administration Portal, click Compute Hosts and select any self-hosted engine node. Click More Actions ( ), then click Disable Global HA Maintenance . Setting the global maintenance mode from the command line Log in to any self-hosted engine node and put it into global maintenance mode: After you have completed any maintenance tasks, disable the maintenance mode:

Commands:
hosted-engine --set-maintenance --mode=local
hosted-engine --set-maintenance --mode=none
hosted-engine --set-maintenance --mode=global
hosted-engine --set-maintenance --mode=none
7.121. libssh2 7.121.1. RHBA-2013:0329 - libssh2 bug fix and enhancement update Updated libssh2 packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libssh2 packages provide a library that implements the SSH2 protocol. Note The libssh2 packages have been upgraded to upstream version 1.4.2, which provides a number of bug fixes and enhancements over the version, including fixes for memory leaks, missing error handling, and incompatibilities in the SSH2 protocol implementation. (BZ#749873) Bug Fixes BZ#741919 With this update, several stability patches have been added to libssh2. As a result, memory leaks, buffer overruns, and null pointer problems are avoided when managing a large number of nodes. BZ#801428 Previously, an insufficient data type was used for certain bit shift operations in the libssh2 code. This behavior caused the curl utility to terminate unexpectedly when downloading files larger than 2 GB over the SSH File Transfer Protocol (SFTP). With this update, the underlying code has been modified to use the correct data type and curl now works as expected in the described scenario. BZ# 804145 Under certain circumstances, libssh2 failed to resume an interrupted key exchange when sending a large amount of data over SSH. Moreover, further data was erroneously sent, which caused the remote site to close the connection immediately. With this update, libssh2 has been modified to properly resume the interrupted key exchange before sending any further data. As a result, the connection remains open and the data transfer proceeds as expected. BZ# 804150 Previously, the function for writing to a channel in libssh2 incorrectly handled error states, which, under certain circumstances, resulted in an infinite loop. The function has been fixed and the error handling now works properly. BZ# 806862 , BZ# 873785 Previously, the window size adjustment in libssh2 did not work properly, which resulted in unclosed connections when transferring huge files over SCP or SFTP, extensive memory consumption or both. The window-adjusting code has been fixed and works now properly for blocks of arbitrary size. BZ# 826511 Previously, libssh2 incorrectly returned the LIBSSH2_ERROR_EAGAIN error code when operating in blocking mode. The error code is used by libssh2 internally to initiate a blocking operation on a socket. The error code was, however, not properly cleared on success and leaked through the public API of libssh2. An upstream patch has been applied to clear the error code prior to initiating the blocking operation, and libssh2 no longer returns LIBSSH2_ERROR_EAGAIN when operating in blocking mode. All users of libssh2 are advised to upgrade to these updated packages, which fix these bugs and add these enhancements. After installing these updated packages, all running applications using libssh2 have to be restarted for this update to take effect.

Commands: