mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Custom triggers The Cryostat 2.4 agent supports custom triggers that are based on MBean metric values. You can configure the Cryostat agent to start JFR recordings dynamically when these custom trigger conditions are met. You can define a custom trigger condition that dynamically starts a JFR recording when this condition is met. A custom trigger condition is based on MBean counters that can cover a range of runtime, memory, thread, and operating system metrics. You can include one or more MBean counter types as part of the custom trigger condition for a JFR recording. You can also specify a duration or time period as part of the trigger condition, which means the conditional values must persist for the specified duration before the condition is met. The Cryostat agent supports smart triggers that continually listen to the value of the specified MBean counters. Triggering occurs if the current values of the specified counters match the configured values in the custom trigger for the specified duration. If triggering occurs, the Cryostat agent dynamically starts the JFR recording at that point. Note A JFR recording will not start dynamically if the custom trigger condition associated with this recording is not met.

Commands:
Chapter 1. Overview The RHEL for SAP Applications or RHEL for SAP Solutions subscriptions provide additional RHEL repositories that contain additional RPM packages required for running SAP applications like S/4HANA, SAP HANA or SAP NetWeaver based SAP products (like ERP or CRM) on RHEL and to use additional features provided by Red Hat specifically for SAP, like the HA solutions for managing S/4HANA, SAP HANA and SAP NetWeaver . Red Hat offers a new RHEL minor release every 6 months. A fix for a problem which has been reported for a given RHEL minor release might be available in a package which is part of one of the following RHEL minor releases. For customers who have to, or want to, keep their system(s) on a certain RHEL minor release for more than 6 months, Red Hat is offering Red Hat Enterprise Linux Extended Maintenance as an Extended Update Support (EUS) Add-On or as Update Services for SAP Solutions (E4S) . These repositories receive important fixes for up to two years (EUS) or four years (E4S) after the release of the corresponding RHEL minor release. The EUS and E4S repositories are only available for certain RHEL minor releases. See the Red Hat Enterprise Linux Life Cycle page for more information on the RHEL release schedule. SAP validates SAP NetWeaver/SAP ABAP Application Platform once per RHEL major release (e. g. RHEL 8), so you can run it on any RHEL minor release once it has been validated on the corresponding RHEL major release (e.g. 8.0, 8.1, 8.2, ... ). In contrast, SAP validates SAP HANA only for specific RHEL minor releases - typically for those RHEL minor releases for which E4S repositories are available. This document provides: instructions for registering your RHEL system to use RHEL for SAP Applications or RHEL for SAP Solutions subscriptions an overview of the repositories that must be enabled based on the combination of SAP products and the RHEL release, and the procedure for enabling the repositories. Note Always verify with SAP and with your hardware partner or infrastructure provider if the SAP product you are planning to use is supported for the RHEL release that is going to be used. When using the EUS or E4S repos, the targeted RHEL minor release must be set via subscription-manager, to ensure that the system does not get updated to a higher RHEL minor release than desired. This document applies only to on-premise systems and to "bring your own subscription" (BYOS) systems on any public cloud platform using Red Hat Subscription Manager (RHSM). It is not applicable to "pay as you go" (PAYG) instances using RHUI on public cloud platforms.

Commands:
7.6. Configure Distribution Mode (Library Mode) The following procedure shows a distributed cache configuration in Red Hat JBoss Data Grid's Library mode. Procedure 7.2. Distributed Cache Configuration Configure the Clustering Element The clustering element's mode parameter's value determines the clustering mode selected for the cache. The sync element's replTimeout parameter specifies the maximum time period in milliseconds for an acknowledgment after a remote call. If the time period ends without any acknowledgment, an exception is thrown. The stateTransfer element specifies how state is transferred when a node leaves or joins the cluster. It uses the following parameters: The chunkSize parameter is the number of cache entries to be transferred in one chunk. The default chunkSize value is 512. The chunkSize depends on many parameters (for example, size of entries) and the best setting needs to be measured. To change the value for larger cache entries, smaller chunks are advisable and for smaller cache entries, increasing the chunkSize offers better performance. The fetchInMemoryState parameter when set to true , requests state information from neighboring caches on start up. This impacts the start up time for the cache. Set the default to true if there is no shared cache store behind to avoid cache inconsistency. The awaitInitialTransfer parameter causes the first call to method CacheManager.getCache() on the joiner node to block and wait until the joining is complete and the cache has finished receiving state from neighboring caches (if fetchInMemoryState is enabled). This option applies to distributed and replicated caches only and is enabled by default. The timeout parameter specifies the maximum time (in milliseconds) the cache waits for responses from neighboring caches with the requested states. If no response is received within the timeout period, the start up process aborts and an exception is thrown. As a result of the failed state transfer, the cache is not available on that instance. Specify Transport Configuration The transport element defines the transport configuration for the cache container as follows: The clusterName parameter specifies the name of the cluster. Nodes can only connect to clusters that share the same name. The distributedSyncTimeout parameter specifies the time to wait to acquire a lock on the distributed lock. This distributed lock ensures that a single cache can transfer state or rehash state at a time. The transportClass parameter specifies a class that represents a network transport for the cache container. Report a bug

Commands:
<clustering mode="distribution"> <sync replTimeout="USD{TIME}" /> <stateTransfer chunkSize="USD{SIZE}" fetchInMemoryState="{true/false}" awaitInitialTransfer="{true/false}" timeout="USD{TIME}" />
<global> <transport clusterName="USD{NAME}" distributedSyncTimeout="USD{TIME}" transportClass="USD{CLASS}" /> </global>
4.24. cachefilesd 4.24.1. RHBA-2011:1679 - cachefilesd bug fix update An updated cachefilesd package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The cachefilesd package manages a kernel module that attempts to improve the performance of selected file systems by using local disk space to cache data read over the network. Bug Fixes BZ# 660347 Prior to this update, cachefilesd used the wrong log level for cull info messages. As a result, the /var/log/messages file could become overloaded. This update reduces the messages to the debug level. Now, /var/log/messages no longer becomes overloaded. BZ# 723890 Prior to this update, cachefilesd depended on a specific version of the SELinux policy package. As a result, only the nominated version was allowed. This update permits the nominated version and any later versions. Now, the SELinux policy dependency works as expected. All users of cachefilesd are advised to upgrade to this updated package, which fixes these bugs.

Commands:
5.2. Is Your Hardware Compatible? Red Hat Enterprise Linux 7 should be compatible with most hardware in systems that were factory built within the last two years. Hardware compatibility is a particularly important concern if you have an older or custom-built system. Because hardware specifications change almost daily, it is recommended that all systems be checked for compatibility. The most recent list of supported hardware can be found in the Red Hat Hardware Compatibility List , available online at https://access.redhat.com/ecosystem/search/#/category/Server . Also see Red Hat Enterprise Linux technology capabilities and limits for general information about system requirements.

Commands:
Chapter 57. Installing KIE Server with Oracle WebLogic Server After you have configured all required system properties in Oracle WebLogic Server, you can install KIE Server with Oracle WebLogic Server to streamline Red Hat Process Automation Manager application management. Prerequisites An Oracle WebLogic Server instance is configured as described in Chapter 56, Configuring Oracle WebLogic Server for KIE Server . Procedure Navigate to the Software Downloads page in the Red Hat Customer Portal (login required), and select the product and version from the drop-down options: Product: Process Automation Manager Version: 7.13.5 Download Red Hat Process Automation Manager 7.13.5 KIE Server for All Supported EE7 Containers . Extract the downloaded rhpam-7.13.5-kie-server-ee7.zip file to a temporary directory. In the WebLogic Administration Console, navigate to Deployments to view all existing applications. Click Install . Navigate to the temporary directory where you downloaded and extracted the rhpam-7.13.5-kie-server-ee7.zip file, and go to rhpam-7.13.5-kie-server-ee7/kie-server.war . Select the kie-server.war file and click to continue. Select Install this deployment as an application as the targeting style and click . Set the application name to kie-server and set the security model to DD Only . Leave the remaining options as default and click to continue. In the Additional Configuration section, choose No, I will review the configuration later and click Finish . 57.1. Verifying the KIE Server installation on Oracle WebLogic Server After you have installed KIE Server on Oracle WebLogic Server, verify that the installation was successful. Prerequisites An Oracle WebLogic Server instance is configured as described in Chapter 56, Configuring Oracle WebLogic Server for KIE Server . KIE Server is installed as described in Chapter 57, Installing KIE Server with Oracle WebLogic Server . Procedure Enter the KIE Server URL http://<HOST>:<PORT>/kie-server/services/rest/server in a web browser. Verify that KIE Server is running. If KIE Server is not running, stop and restart the Oracle WebLogic Server instance and try again to access the KIE Server URL.

Commands:
Preface The Red Hat Enterprise Linux 6.6 Technical Notes list and document the changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications between minor release Red Hat Enterprise Linux 6.5 and minor release Red Hat Enterprise Linux 6.6. For system administrators and others planning Red Hat Enterprise Linux 6.6 upgrades and deployments, the Technical Notes provide a single, organized record of the bugs fixed in, features added to, and Technology Previews included with this new release of Red Hat Enterprise Linux. For auditors and compliance officers, the Red Hat Enterprise Linux 6.6 Technical Notes provide a single, organized source for change tracking and compliance testing. For every user, the Red Hat Enterprise Linux 6.6 Technical Notes provide details of what has changed in this new release.

Commands:
Chapter 8. Setting the load balancer for host registration You can configure Satellite to register clients through a load balancer when using the host registration feature. You will be able to register hosts to the load balancer instead of Capsule. The load balancer will decide through which Capsule to register the host at the time of request. Upon registration, the subscription manager on the host will be configured to manage content through the load balancer. Prerequisites You configured SSL certificates on all Capsule Servers. For more information, see the following sections: Chapter 3, Configuring Capsule Servers with default SSL certificates for load balancing . Chapter 4, Configuring Capsule Servers with custom SSL certificates for load balancing . Chapter 5, Configuring Capsule Servers with default SSL certificates for load balancing (with Puppet) . Chapter 6, Configuring Capsule Servers with custom SSL certificates for load balancing (with Puppet) . You enabled Registration and Templates plugins on all Capsule Servers: Procedure On all Capsule Servers, set the registration and template URLs using satellite-installer : In the Satellite web UI, navigate to Infrastructure > Capsules . For each Capsule, click the dropdown menu in the Actions column and select Refresh .

Commands:
satellite-installer --foreman-proxy-registration true --foreman-proxy-templates true
satellite-installer --foreman-proxy-registration-url "https:// loadbalancer.example.com :9090" --foreman-proxy-template-url "http:// loadbalancer.example.com :8000"
Chapter 2. Architectures Red Hat Enterprise Linux 8.8 is distributed with the kernel version 4.18.0-477.10, which provides support for the following architectures: AMD and Intel 64-bit architectures The 64-bit ARM architecture IBM Power Systems, Little Endian 64-bit IBM Z Make sure you purchase the appropriate subscription for each architecture. For more information, see Get Started with Red Hat Enterprise Linux - additional architectures . For a list of available subscriptions, see Subscription Utilization on the Customer Portal.

Commands:
Chapter 18. Enabling faster client IO or recovery IO during OSD backfill During a maintenance window, you may want to favor either client IO or recovery IO. Favoring recovery IO over client IO will significantly reduce OSD recovery time. The valid recovery profile options are balanced , high_client_ops , and high_recovery_ops . Set the recovery profile using the following procedure. Prerequisites Download the OpenShift Data Foundation command line interface (CLI) tool. With the Data Foundation CLI tool, you can effectively manage and troubleshoot your Data Foundation environment from a terminal. You can find a compatible version and download the CLI tool from the customer portal . Procedure Check the current recovery profile: Modify the recovery profile: Replace option with either balanced , high_client_ops , or high_recovery_ops . Verify the updated recovery profile:

Commands:
odf get recovery-profile
odf set recovery-profile <option>
odf get recovery-profile
Chapter 10. Using Image Builder API The Image Builder API contains examples for using various types of request. Administrators and developers can use the Image Builder API to write custom scripts to integrate Image Builder services with third-party applications. 10.1. Generating an access token for the Image Builder API queries The Image Builder API queries require an active access token. The access token expires after 900 seconds after its creation. To generate the access token, follow the steps below. Prerequisites You have a RHEL subscription. You have a service account in the Red Hat Hybrid Cloud Console. For details, see Creating a service account . Procedure To generate the access token, include the following code in your script in the Authorization header with the value Bearer USDACCESS_TOKEN : CLIENT_ID=" YOUR_CLIENT_ID " CLIENT_SECRET=" YOUR_CLIENT_SECRET " ACCESS_TOKEN=USD( \ curl -d "client_id=USDCLIENT_ID" \ -d "client_secret=USDCLIENT_SECRET" \ -d "grant_type=client_credentials" \ "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" \ -d "scope=api.console" \ | jq -r .access_token \ ) Replace YOUR_CLIENT_ID with the client ID, and YOUR_CLIENT_SECRET with the client secret from your service account . Additional resources For more information about Image Builder API, see Image Builder API catalogue .

Commands:
CLIENT_ID=" YOUR_CLIENT_ID " CLIENT_SECRET=" YOUR_CLIENT_SECRET " ACCESS_TOKEN=USD( curl -d "client_id=USDCLIENT_ID" -d "client_secret=USDCLIENT_SECRET" -d "grant_type=client_credentials" "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" -d "scope=api.console" | jq -r .access_token )
Chapter 1. Red Hat build of OpenJDK overview OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in three versions: 8u, 11u, and 17u. Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Container Catalog.

Commands:
22.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with rsync . Different types all you to configure flexible access: public_content_t This is a generic type used for the location of files (and the actual files) to be shared using rsync . If a special directory is created to house files to be shared with rsync , the directory and its contents need to have this label applied to them. rsync_exec_t This type is used for the /usr/bin/rsync system binary. rsync_log_t This type is used for the rsync log file, located at /var/log/rsync.log by default. To change the location of the file rsync logs to, use the --log-file=FILE option to the rsync command at run-time. rsync_var_run_t This type is used for the rsyncd lock file, located at /var/run/rsyncd.lock . This lock file is used by the rsync server to manage connection limits. rsync_data_t This type is used for files and directories which you want to use as rsync domains and isolate them from the access scope of other services. Also, the public_content_t is a general SELinux context type, which can be used when a file or a directory interacts with multiple services (for example, FTP and NFS directory as an rsync domain). rsync_etc_t This type is used for rsync-related files in the /etc directory.

Commands:
6.4. VDB Definition: The model Element Attributes name This is the name of the model is used as a top level schema name for all of the metadata imported from the connector. The name must be unique among all Models in the VDB and must not contain the '.' character. version This is the version of the VDB (it should be an positive integer). This determines the deployed directory location (see Name), and provides an explicit versioning mechanism for the VDB name. visibility By default this value is set to "true". When the value is set to "false", this model will not be visible to JDBC metadata queries. Usually it is used to hide a model from client applications that must not directly issue queries against it. However, this does not prohibit either client applications or other view models from using it, if they know its schema. Source Element A source is a named binding of a translator and connection source to a model. name The name of the source to use for this model. This can be any name you like, but will typically be the same as the model name. Having a name different from the model name is only useful in multi-source scenarios. In multi-source, the source names under a given model must be unique. If you have the same source bound to multiple models it may have the same name for each. An exception will be raised if the same source name is used for different sources. translator-name The name or type of the JBoss Data Virtualization Translator to use. Possible values include the built-in types (ws, file, ldap, oracle, sqlserver, db2, derby, etc.) and translators defined in the translators section. connection-jndi-name The JNDI name of this source's connection factory. Check out the deploying VDB dependencies section for info. You also need to deploy these connection factories before you can deploy the VDB. Property Elements importer.<propertyname> Property to be used by the connector importer for the model for purposes importing metadata. See possible property name/values in the Translator specific section. Note that using these properties you can narrow or widen the data elements available for integration. Metadata Element The optional metadata element defines the metadata repository type and optional raw metadata to be consumed by the metadata repository. type The metadata repository type. Defaults to INDEX for Designer VDBs and NATIVE for non-Designer VDB source models. For all other deployments/models a value must be specified. Built-in types include DDL, NATIVE, INDEX, and DDL-FILE. The usage of the raw text varies with the by type. The raw text is not used with NATIVE and INDEX (only for Designer VDBs) metadata repositories. The raw text for DDL is expected to be a series of DDL statements that define the schema. DDL-FILE (used only with zip deployments) is similar to DDL, except that the raw text specifies an absolute path relative to the vdb root of the location of a file containing the DDL. See also about a Custom Metadata Repository in Red Hat JBoss Development Guide: Server Development .

Commands:
Chapter 1. Device Mapper Multipathing Device Mapper Multipathing (DM-Multipath) allows you to configure multiple I/O paths between server nodes and storage arrays into a single device. These I/O paths are physical SAN connections that can include separate cables, switches, and controllers. Multipathing aggregates the I/O paths, creating a new device that consists of the aggregated paths. 1.1. Overview of DM-Multipath DM-Multipath can be used to provide: Redundancy DM-Multipath can provide failover in an active/passive configuration. In an active/passive configuration, only half the paths are used at any time for I/O. If any element of an I/O path (the cable, switch, or controller) fails, DM-Multipath switches to an alternate path. Improved Performance DM-Multipath can be configured in active/active mode, where I/O is spread over the paths in a round-robin fashion. In some configurations, DM-Multipath can detect loading on the I/O paths and dynamically re-balance the load. Figure 1.1, "Active/Passive Multipath Configuration with One RAID Device" shows an active/passive configuration with two I/O paths from the server to a RAID device. There are 2 HBAs on the server, 2 SAN switches, and 2 RAID controllers. Figure 1.1. Active/Passive Multipath Configuration with One RAID Device In this configuration, there is one I/O path that goes through hba1, SAN1, and controller 1 and a second I/O path that goes through hba2, SAN2, and controller2. There are many points of possible failure in this configuration: HBA failure FC cable failure SAN switch failure Array controller port failure With DM-Multipath configured, a failure at any of these points will cause DM-Multipath to switch to the alternate I/O path. Figure 1.2, "Active/Passive Multipath Configuration with Two RAID Devices" shows a more complex active/passive configuration with 2 HBAs on the server, 2 SAN switches, and 2 RAID devices with 2 RAID controllers each. Figure 1.2. Active/Passive Multipath Configuration with Two RAID Devices As in the example shown in Figure 1.1, "Active/Passive Multipath Configuration with One RAID Device" , there are two I/O paths to each RAID device. With DM-Multipath configured, a failure at any of the points of the I/O path to either of the RAID devices will cause DM-Multipath to switch to the alternate I/O path for that device. Figure 1.3, "Active/Active Multipath Configuration with One RAID Device" shows an active/active configuration with 2 HBAs on the server, 1 SAN switch, and 2 RAID controllers. There are four I/O paths from the server to a storage device: hba1 to controller1 hba1 to controller2 hba2 to controller1 hba2 to controller2 In this configuration, I/O can be spread among those four paths. Figure 1.3. Active/Active Multipath Configuration with One RAID Device

Commands: