mtpti5iD/redhat-docs_dataset huggingface dataset:
4.4. Configuring Multiple Monitors 4.4.1. Configuring Multiple Displays for Red Hat Enterprise Linux Virtual Machines A maximum of four displays can be configured for a single Red Hat Enterprise Linux virtual machine when connecting to the virtual machine using the SPICE protocol. Start a SPICE session with the virtual machine. Open the View drop-down menu at the top of the SPICE client window. Open the Display menu. Click the name of a display to enable or disable that display. Note By default, Display 1 is the only display that is enabled on starting a SPICE session with a virtual machine. If no other displays are enabled, disabling this display will close the session. 4.4.2. Configuring Multiple Displays for Windows Virtual Machines A maximum of four displays can be configured for a single Windows virtual machine when connecting to the virtual machine using the SPICE protocol. Click Compute Virtual Machines and select a virtual machine. With the virtual machine in a powered-down state, click Edit . Click the Console tab. Select the number of displays from the Monitors drop-down list. Note This setting controls the maximum number of displays that can be enabled for the virtual machine. While the virtual machine is running, additional displays can be enabled up to this number. Click OK . Start a SPICE session with the virtual machine. Open the View drop-down menu at the top of the SPICE client window. Open the Display menu. Click the name of a display to enable or disable that display. Note By default, Display 1 is the only display that is enabled on starting a SPICE session with a virtual machine. If no other displays are enabled, disabling this display will close the session.

Commands:
Chapter 3. Organizations, Locations, and Life Cycle Environments Red Hat Satellite takes a consolidated approach to Organization and Location management. System administrators define multiple Organizations and multiple Locations in a single Satellite Server. For example, a company might have three Organizations (Finance, Marketing, and Sales) across three countries (United States, United Kingdom, and Japan). In this example, Satellite Server manages all Organizations across all geographical Locations, creating nine distinct contexts for managing systems. In addition, users can define specific locations and nest them to create a hierarchy. For example, Satellite administrators might divide the United States into specific cities, such as Boston, Phoenix, or San Francisco. Figure 3.1. Example Topology for Red Hat Satellite Satellite Server defines all locations and organizations. Each respective Satellite Capsule Server synchronizes content and handles configuration of systems in a different location. The main Satellite Server retains the management function, while the content and configuration is synchronized between the main Satellite Server and a Satellite Capsule Server assigned to certain locations. 3.1. Organizations Organizations divide Red Hat Satellite resources into logical groups based on ownership, purpose, content, security level, or other divisions. You can create and manage multiple organizations through Red Hat Satellite, then divide and assign your subscriptions to each individual organization. This provides a method of managing the content of several individual organizations under one management system. 3.2. Locations Locations divide organizations into logical groups based on geographical location. Each location is created and used by a single account, although each account can manage multiple locations and organizations. 3.3. Life Cycle Environments Application life cycles are divided into life cycle environments which represent each stage of the application life cycle. Life cycle environments are linked to form an environment path . You can promote content along the environment path to the life cycle environment when required. For example, if development ends on a particular version of an application, you can promote this version to the testing environment and start development on the version. Figure 3.2. An Environment Path Containing Four Environments

Commands:
Chapter 3. Red Hat build of OpenJDK features 3.1. New features and enhancements This section describes the new features introduced in this release. It also contains information about changes in the existing features. Note For all the other changes and security fixes, see https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004689.html . 3.1.1. Added -groupname option to keytool key pair generation command A new -groupname option has been added to the keytool -genkeypair command. Use the -groupname option to specify a named elliptic curve (EC) group when generating a key pair. For example, the following command generates an EC key pair using the secp384r1 curve: keytool -genkeypair -keyalg EC -groupname secp384r1 It is recommended that you use the -groupname option over the -keysize option, because there might be multiple curves of the same size. For more information, see JDK-8213821 . 3.1.2. Added support for X25519 and X448 in TLS The named elliptic curve groups x25519 and x448 are now available for JSSE key agreement in TLS versions 1.0 to 1.3. The curve group x25519 is the most preferred of the default enabled named groups. The default ordered list is as follows: x25519 secp256r1 secp384r1 secp521r1 x448 secp256k1 ffdhe2048 ffdhe3072 ffdhe4096 ffdhe6144 ffdhe8192 Use the system property jdk.tls.namedGroups to override the default list. For more information, see JDK-8225764 . 3.1.3. Added default native GSS-API library on Windows A native GSS-API library has been added to JDK on the Windows platform. The library is client-side only and uses the default credentials. It is activated by setting the sun.security.jgss.native system property to "true". A user can still make use of a third-party native GSS-API library instead by setting the system property sun.security.jgss.lib to its path. For more information, see JDK-8214079 . 3.1.4. Added jarsigner to preserve POSIX file permission and symlink attribute When signing a file that contains POSIX file permission or symlink attributes, jarsigner now preserves these attributes in the newly signed file but warns that these attributes are unsigned and not protected by the signature. The same warning is printed during the jarsigner -verify operation for such files. Note The jar tool does not read or write these attributes. This change is more visible to tools like unzip where these attributes are preserved. For more information, see JDK-8248263 . Revised on 2024-05-09 16:46:18 UTC

Commands:
6.3. Remote Authentication Using GSSAPI In the context of Red Hat Virtualization, remote authentication refers to authentication that is handled by a remote service, not the Red Hat Virtualization Manager. Remote authentication is used for user or API connections coming to the Manager from within an AD, IdM, or RHDS domain. The Red Hat Virtualization Manager must be configured by an administrator using the engine-manage-domains tool to be a part of an RHDS, AD, or IdM domain. This requires that the Manager be provided with credentials for an account from the RHDS, AD, or IdM directory server for the domain with sufficient privileges to join a system to the domain. After domains have been added, domain users can be authenticated by the Red Hat Virtualization Manager against the directory server using a password. The Manager uses a framework called the Simple Authentication and Security Layer (SASL) which in turn uses the Generic Security Services Application Program Interface (GSSAPI) to securely verify the identity of a user, and ascertain the authorization level available to the user. Figure 6.1. GSSAPI Authentication

Commands:
Chapter 2. Configuring the OpenShift Container Platform TLS component for builds The tls component of the QuayRegistry custom resource definition (CRD) allows you to control whether SSL/TLS are managed by the Red Hat Quay Operator, or self managed. In its current state, Red Hat Quay does not support the builds feature, or the builder workers, when the tls component is managed by the Red Hat Quay Operator. When setting the tls component to unmanaged , you must supply your own ssl.cert and ssl.key files. Additionally, if you want your cluster to support builders , or the worker nodes that are responsible for building images, you must add both the Quay route and the builder route name to the SAN list in the certificate. Alternatively, however, you could use a wildcard. The following procedure shows you how to add the builder route. Prerequisites You have set the tls component to unmanaged and uploaded custom SSL/TLS certificates to the Red Hat Quay Operator. For more information, see SSL and TLS for Red Hat Quay . Procedure In the configuration file that defines your SSL/TLS certificate parameters, for example, openssl.cnf , add the following information to the certificate's Subject Alternative Name (SAN) field. For example: # ... [alt_names] <quayregistry-name>-quay-builder-<namespace>.<domain-name>:443 # ... For example: # ... [alt_names] example-registry-quay-builder-quay-enterprise.apps.cluster-new.gcp.quaydev.org:443 # ...

Commands:
[alt_names] <quayregistry-name>-quay-builder-<namespace>.<domain-name>:443
[alt_names] example-registry-quay-builder-quay-enterprise.apps.cluster-new.gcp.quaydev.org:443
Chapter 6. Upgrading hosts to major Red Hat Enterprise Linux release You can use a job template to upgrade your Red Hat Enterprise Linux hosts to the major release. Below upgrade paths are possible: Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9 Prerequisites Ensure that your Red Hat Enterprise Linux hosts meet the requirements for the upgrade. For Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 upgrade, see Planning an upgrade in Upgrading from RHEL 7 to RHEL 8 . For Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9 upgrade, see Planning an upgrade to RHEL 9 in Upgrading from RHEL 8 to RHEL 9 . Prepare your Red Hat Enterprise Linux hosts for the upgrade. For Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 upgrade, see Preparing a RHEL 7 system for the upgrade in Upgrading from RHEL 7 to RHEL 8 . For Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9 upgrade, see Preparing a RHEL 8 system for the upgrade in Upgrading from RHEL 8 to RHEL 9 . Distribute Satellite SSH keys to the hosts that you want to upgrade. For more information, see Section 12.14, "Distributing SSH keys for remote execution" . Procedure On Satellite, enable the Leapp plugin: If you are using a custom job template for the Leapp pre-upgrade check, configure the leapp_preupgrade remote execution feature to point to your template: In the Satellite web UI, navigate to Administer > Remote Execution Features . Click leapp_preupgrade . In the Job Template dropdown menu, select your template. Click Submit . In the Satellite web UI, navigate to Hosts > All Hosts . Select the hosts that you want to upgrade to the major Red Hat Enterprise Linux version. From the Schedule Remote Job list, select Preupgrade check with Leapp . When the check is finished, click the Leapp preupgrade report tab to see if Leapp has found any issues on your hosts. Issues that have the Inhibitor flag are considered crucial and are likely to break the upgrade procedure. Issues that have the Has Remediation flag contain remediation that can help you fix the issue. Click an issue that is flagged as Has Remediation to expand it. If the issue contains a remediation Command , you can fix it directly from Satellite using remote execution. Select the issue. If the issue contains only a remediation Hint , use the hint to fix the issue on the host manually. Repeat this step for other issues. After you selected any issues with remediation commands, click Fix Selected and submit the job. After the issues are fixed, click Rerun , and then click Submit to run the pre-upgrade check again to verify that the hosts you are upgrading do not have any issues and are ready to be upgraded. If the pre-upgrade check verifies that the hosts do not have any issues, click Run Upgrade and click Submit to start the upgrade. Alternatively, you can upgrade your host by selecting Upgrade with Leapp in the Schedule Remote Job drop down menu.

Commands:
satellite-installer --enable-foreman-plugin-leapp
Chapter 1. Kernel The kernel shipped in Red Hat Enterprise Linux 6.5 includes several hundred bug fixes for, and enhancements to the Linux kernel. For details concerning important bugs fixed and enhancements added to the kernel for this release, refer to the kernel section of the Red Hat Enterprise Linux 6.5 Technical Notes . Support for PMC-Sierra Cards and Controllers The pm8001/pm80xx driver adds support for PMC-Sierra Adaptec Series 6H and 7H SAS/SATA HBA cards as well as PMC Sierra 8081, 8088, and 8089 chip based SAS/SATA controllers. Configurable Timeout for Unresponsive Devices In certain storage configurations (for example, configurations with many LUNs), the SCSI error handling code can spend a large amount of time issuing commands such as TEST UNIT READY to unresponsive storage devices. A new sysfs parameter, eh_timeout , has been added to the SCSI device object, which allows configuration of the timeout value for TEST UNIT READY and REQUEST SENSE commands used by the SCSI error handling code. This decreases the amount of time spent checking these unresponsive devices. The default value of eh_timeout is 10 seconds, which was the timeout value used prior to adding this functionality. Configuration of Maximum Time for Error Recovery A new sysfs parameter eh_deadline has been added to the SCSI host object, which enables configuring the maximum amount of time that the SCSI error handling will attempt to perform error recovery, before giving up and resetting the entire host bus adapter (HBA). The value of this parameter is specified in seconds, and the default is zero, which disables the time limit and allows all of the error recovery to take place. In addition to using sysfs , a default value can be set for all SCSI HBAs using the eh_deadline kernel parameter. Lenovo X220 Touchscreen Support Red Hat Enterprise Linux 6.5 now supports Lenovo X220 touchscreen. New Supported Compression Formats for makedumpfile In Red Hat Enterprise Linux 6.5, the makedumpfile utility supports the LZO and snappy compression formats. Using these compression formats instead of the zlib format is quicker, in particular when compressing data with randomized content.

Commands:
Chapter 25. level The logging level from various sources, including rsyslog(severitytext property) , a Python logging module, and others. The following values come from syslog.h , and are preceded by their numeric equivalents : 0 = emerg , system is unusable. 1 = alert , action must be taken immediately. 2 = crit , critical conditions. 3 = err , error conditions. 4 = warn , warning conditions. 5 = notice , normal but significant condition. 6 = info , informational. 7 = debug , debug-level messages. The two following values are not part of syslog.h but are widely used: 8 = trace , trace-level messages, which are more verbose than debug messages. 9 = unknown , when the logging system gets a value it doesn't recognize. Map the log levels or priorities of other logging systems to their nearest match in the preceding list. For example, from python logging , you can match CRITICAL with crit , ERROR with err , and so on. Data type keyword Example value info

Commands:
Appendix A. VDSM Service and Hooks The VDSM service is used by the Red Hat Virtualization Manager to manage Red Hat Virtualization Hosts (RHVH) and Red Hat Enterprise Linux hosts. VDSM manages and monitors the host's storage, memory, and network resources. It also coordinates virtual machine creation, statistics gathering, log collection and other host administration tasks. VDSM is run as a daemon on each host managed by Red Hat Virtualization Manager. It answers XML-RPC calls from clients. The Red Hat Virtualization Manager functions as a VDSM client. VDSM is extensible via hooks. Hooks are scripts executed on the host when key events occur. When a supported event occurs VDSM runs any executable hook scripts in /usr/libexec/vdsm/hooks/ nn_event-name / on the host in alphanumeric order. By convention each hook script is assigned a two digit number, included at the front of the file name, to ensure that the order in which the scripts will be run in is clear. You are able to create hook scripts in any programming language, Python will however be used for the examples contained in this chapter. Note that all scripts defined on the host for the event are executed. If you require that a given hook is only executed for a subset of the virtual machines which run on the host then you must ensure that the hook script itself handles this requirement by evaluating the Custom Properties associated with the virtual machine. Warning VDSM hooks can interfere with the operation of Red Hat Virtualization. A bug in a VDSM hook has the potential to cause virtual machine crashes and loss of data. VDSM hooks should be implemented with caution and tested rigorously. The Hooks API is new and subject to significant change in the future. You can extend VDSM with event-driven hooks. Extending VDSM with hooks is an experimental technology, and this chapter is intended for experienced developers. By setting custom properties on virtual machines it is possible to pass additional parameters, specific to a given virtual machine, to the hook scripts. A.1. Installing a VDSM hook By default, VDSM hooks are not installed. If you need a specific hook, you must install it manually. Prerequisites The host repository must be enabled. You are logged into the host with root permissions. Procedure Get a list of available hooks: Put the host in maintenance mode. Install the desired VDSM hook package on the host: For example, to install the vdsm-hook-vhostmd package on the host, enter the following: Restart the host. Additional resources Enabling the Red Hat Virtualization Host Repository Enabling the Red Hat Enterprise Linux host Repositories

Commands:
dnf list vdsm\*hook\*
dnf install <vdsm-hook-name>
dnf install vdsm-hook-vhostmd
Chapter 2. Embedded caches Add Data Grid as a dependency to your Java project and use embedded caches that increase application performance and give you capabilities to handle complex use cases. 2.1. Embedded cache tutorials You can run embedded cache tutorials directly in your IDE or from the command line as follows: USD ./mvnw -s /path/to/maven-settings.xml clean package exec:exec Tutorial link Description Distributed caches Demonstrates how Distributed Caches work. Replicated caches Demonstrates how Replicated Caches work. Invalidated caches Demonstrates how Invalidated Caches work. Transactions Demonstrates how transactions work. Streams Demonstrates how Distributed Streams work. JCache integration Demonstrates how JCache works. Functional Maps Demonstrates how Functional Map API works. Map API Demonstrates how the Map API works with Data Grid caches. Multimap Demonstrates how to use Multimap. Queries Uses Data Grid Query to perform full-text queries on cache values. Clustered Listeners Detects when data changes in an embedded cache with Clustered Listeners. Counters Demonstrates how to use an embedded Clustered Counter. Clustered Locks Demonstrates how to use an embedded Clustered Lock. Clustered execution Demonstrates how to use an embedded Clustered Counter. Data Grid documentation You can find more resources about embedded caches in our documentation at: Embedding Data Grid Caches Querying Data Grid caches 2.2. Kubernetes and Openshift tutorial This tutorial contains instructions on how to run Infinispan library mode (as a microservice) in Kubernetes/OpenShift. Prerequisites: Maven and Docker daemon running in the background. Prerequisites A running Openshift or Kubernetes cluster Building the tutorial This tutorial is built using the maven command: ./mvnw package Note that target/ directory contains additional directories like docker (with generated Dockerfile) and classes/META-INF/jkube with Kubernetes and OpenShift deployment templates. Tip If the Docker Daemon is down, the build will omit processing Dockerfiles. Use docker profile to turn it on manually. Deploying the tutorial to Kubernetes This is handle by the JKube maven plugin, just invoke: mvn k8s:build k8s:push k8s:resource k8s:apply -Doptions.image=<IMAGE_NAME> 1 1 IMAGE_NAME must be replaced with the FQN of the container to deploy to Kubernetes. This container must be created in a repository that you have permissions to push to and is accessible from within your Kubernetes cluster. Viewing and scaling up Everything should be up and running at this point. Now login into the OpenShift or Kubernetes cluster and scale the application kubectl scale --replicas=3 deployment/USD(kubectl get rs --namespace=myproject | grep infinispan | awk '{print USD1}') --namespace=myproject Undeploying the tutorial This is handled by the JKube maven plugin, just invoke:

Commands:
./mvnw -s /path/to/maven-settings.xml clean package exec:exec
./mvnw package
mvn k8s:build k8s:push k8s:resource k8s:apply -Doptions.image=<IMAGE_NAME> 1
scale --replicas=3 deployment/USD(kubectl get rs --namespace=myproject | grep infinispan | awk '{print USD1}') --namespace=myproject
mvn k8s:undeploy
Chapter 9. Importers 9.1. Importers The Import Wizard provides a means to create a model based on the structure of a data source, to convert existing metadata (that is, WSDL or XML Schema) into a source model or to load existing metadata files into the current VDB. To launch the Import Wizard, select the File > Import action or select a project, folder or model in the tree and right-click select Import... Figure 9.1. Import Wizard

Commands:
Preface Welcome to the Red Hat JBoss Core Services version 2.4.57 Service Pack 5 release. Red Hat JBoss Core Services Apache HTTP Server is an open source web server developed by the Apache Software Foundation . The Apache HTTP Server includes the following features: Implements the current HTTP standards, including HTTP/1.1 and HTTP/2. Supports Transport Layer Security (TLS) encryption through OpenSSL , which provides secure connections between the web server and web clients. Supports extensible functionality through the use of modules, some of which are included with the Red Hat JBoss Core Services Apache HTTP Server. This release of Red Hat JBoss Core Services includes some important security updates.

Commands:
5.361. xmlrpc-c 5.361.1. RHBA-2012:0954 - xmlrpc-c bug fix update Updated xmlrpc-c packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The xmlrpc-c packages provide a network protocol to allow a client program to make a simple RPC (remote procedure call) over the Internet. It converts an RPC into an XML document, sends it to a remote server using HTTP, and gets back the response in XML. Bug Fixes BZ# 653702 Prior to this update, the "xmlrpc-c-config client --libs" command returned unprocessed output, making it difficult to discern important information from it. This bug has been fixed and the output of the command is now properly pre-processed by the autoconf utility. BZ# 741641 A memory leak was discovered in the xmlrpc-c library by the valgrind utility. A patch has been provided to address this bug and the memory leak no longer occurs. Users of xmlrpc-c are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Release Notes Red Hat build of Keycloak 24.0 Red Hat Customer Content Services

Commands:
bin/kc.[sh|bat] start --spi-brute-force-protector-default-brute-force-detector-allow-concurrent-requests=true
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: resources: requests: cpu: 1200m memory: 896Mi limits: cpu: 6 memory: 3Gi
apiVersion: k8s.keycloak.org/v2alpha1 kind: Keycloak metadata: name: example-kc spec: cache: configMapFile: name: my-configmap key: config.xml
spec: truststores: mystore: secret: name: mystore-secret myotherstore: secret: name: myotherstore-secret