mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. The Notification/Listener API Red Hat JBoss Data Grid provides a listener API that provides notifications for events as they occur. Clients can choose to register with the listener API for relevant notifications. This annotation-driven API operates on cache-level events and cache manager-level events. Report a bug 7.1. Listener Example The following example defines a listener in Red Hat JBoss Data Grid that prints some information each time a new entry is added to the cache: Example 7.1. Configuring a Listener Report a bug

Commands:
@Listener public class PrintWhenAdded { @CacheEntryCreated public void print(CacheEntryCreatedEvent event) { System.out.println("New entry " + event.getKey() + " created in the cache"); } }
3.2. Example: List Data Center Collection Red Hat Virtualization Manager creates a Default data center on installation. This example uses the Default data center as the basis for our virtual environment. The following request retrieves a representation of the data center collection: Example 3.2. List data center collection Request: cURL command: Result: Note the id code of your Default data center. This code identifies this data center in relation to other resources of your virtual environment. The data center also contains a link to the storagedomains sub-collection. The data center uses this sub-collection to attach storage domains from the storagedomains main collection, which this example covers later.

Commands:
GET /ovirt-engine/api/datacenters HTTP/1.1 Accept: application/xml
curl -X GET -H "Accept: application/xml" -u [USER:PASS] --cacert [CERT] https:// [RHEVM Host] :443/ovirt-engine/api/datacenters
HTTP/1.1 200 OK Content-Type: application/xml <data_centers> <data_center href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab" id="00000002-0002-0002-0002-0000000003ab"> <name>Default</name> <description>The default Data Center</description> <link rel="storagedomains"/> href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab/storagedomains" <link rel="clusters"/> href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab/clusters" <link rel="networks"/> href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab/networks" <link rel="permissions"/> href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab/permissions" <link rel="quotas"/> href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab/quotas" <link rel="iscsibonds"/> href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab/iscsibonds" <link rel="qoss"/> href="/ovirt-engine/api/datacenters/00000002-0002-0002-0002-0000000003ab/qoss" <local>false</local> <storage_format>v3</storage_format> <version major="4" minor="0"/> <supported_versions> <version major="4" minor="0"/> </supported_versions> <status> <state>up</state> </status> </data_center> </data_centers>
Chapter 2. Role-Based Parameters Substitute _ROLE_ with the name of the role. For example, for _ROLE_Count use ControllerCount . Parameter Description _ROLE_AnyErrorsFatal NO DESCRIPTION The default value is True . _ROLE_Count The number of nodes to deploy in a role. The default value is 1 . _ROLE_ExtraConfig Role specific additional hiera configuration to inject into the cluster. _ROLE_ExtraGroupVars Optional extra Ansible group vars. _ROLE_HostnameFormat Format for node hostnames. Note that %index% is translated into the index of the node (e.g 0/1/2) and %stackname% is replaced with the stack name (e.g overcloud ). The default value is %stackname%-_role_-%index% . _ROLE_MaxFailPercentage NO DESCRIPTION The default value is 15 . _ROLE_NetworkDeploymentActions OpenStack Orchestration (heat) action when to apply network configuration changes. _ROLE_Parameters Optional Role Specific parameters to be provided to service. _ROLE_RemovalPolicies List of resources to be removed from the role's ResourceGroup when doing an update that requires removal of specific resources. _ROLE_RemovalPoliciesMode How to handle change to RemovalPolicies for ROLE ResourceGroup when doing an update. Default mode append will append to the existing blacklist and update would replace the blacklist. The default value is append . _ROLE_SchedulerHints Optional scheduler hints to pass to OpenStack Compute (nova). _ROLE_Services A list of service resources (configured in the OpenStack Orchestration (heat) resource_registry) which represent nested stacks for each service that should get installed on the ROLE role.

Commands:
Chapter 15. Enabling and enforcing GNOME Shell extensions GNOME Shell Extensions are add-ons that enhance the functionality and appearance of the GNOME desktop environment. Users can enable extensions for their own desktop session or for all users on the sytem. 15.1. Enabling system-wide GNOME Shell extensions You can automatically enable GNOME extensions for all users, eliminating the need for individual installations. Existing users with personalized extensions are not affected. Prerequisites Administrative access Procedure Download the extension archive from the GNOME Extensions website. Extract the archive into the /usr/share/gnome-shell/extensions/ directory: Replace <extension-file.zip> with the name of the extension zip file. Adjust the permissions to ensure that the extension files are readable and executable by everyone: Replace <extension-directory> with the name of the extension directory. Create a new /etc/dconf/db/local.d/00-extensions file with the following content: Replace the UUIDs ( myextension1@myname.example.com , myextension2@myname.example.com) with the ones you want to enable. You can find the UUID of an extension on its GNOME Shell Extensions website page. Apply the changes to the system databases: After completing these steps, the specified extensions are enabled by default for all new users on your system. 15.2. Restricting GNOME Shell extensions By locking down specific GNOME Shell extensions, you can ensuring that a predefined set of extensions is consistently available to all users. You can configure a set of mandatory extensions and prevent users from modifying them. The specified extensions are mandatory for all users, and the Looking Glass tool is disabled to ensure compliance with the predefined configuration. Prerequisites Administrative access Procedure Create a new /etc/dconf/db/local.d/00-extensions file with the following content: Replace the UUIDs ( myextension1@myname.example.com , myextension2@myname.example.com) with the ones you want to enable. You can find the UUID of an extension on its GNOME Shell Extensions website page. To prevent users from changing these settings, create a new /etc/dconf/db/local.d/locks/extensions file with the following content: Apply the changes to the system databases: Extensions that are not listed in the org.gnome.shell.enabled-extensions file are not loaded by the GNOME Shell, preventing the user from using them.

Commands:
unzip -q <extension-file.zip> -d /usr/share/gnome-shell/extensions/
chmod -R 755 /usr/share/gnome-shell/extensions/<extension-directory>/
[org/gnome/shell] enabled-extensions=['myextension1@myname.example.com', 'myextension2@myname.example.com']
dconf update
[org/gnome/shell] enabled-extensions=['myextension1@myname.example.com', 'myextension2@myname.example.com'] development-tools=false
/org/gnome/shell/enabled-extensions /org/gnome/shell/development-tools
dconf update
15.2.4. Upgrading Upgrading a package is similar to installing one. Type the following command at a shell prompt: As part of upgrading a package, RPM automatically uninstalls any old versions of the foo package. In fact, you may want to always use -U to install packages which works even when there are no versions of the package installed. Note You don't want to use the -U option for installing kernel packages because RPM replaces the kernel package. This does not affect a running system, but if the new kernel is unable to boot during your restart, there would be no other kernel to boot instead. Using the -i option adds the kernel to your GRUB boot menu ( /etc/grub.conf ). Similarly, removing an old, unneeded kernel removes the kernel from GRUB. Because RPM performs intelligent upgrading of packages with configuration files, you may see a message like the following: This message means that your changes to the configuration file may not be forward compatible with the new configuration file in the package, so RPM saved your original file and installed a new one. You should investigate the differences between the two configuration files and resolve them as soon as possible, to ensure that your system continues to function properly. Upgrading is really a combination of uninstalling and installing, so during an RPM upgrade you can encounter uninstalling and installing errors, plus one more. If RPM thinks you are trying to upgrade to a package with an older version number, the output is similar to the following: To force RPM to upgrade anyway, use the --oldpackage option:

Commands:
-Uvh foo-2.0-1.i386.rpm
saving /etc/foo.conf as /etc/foo.conf.rpmsave
package foo-2.0-1 (which is newer than foo-1.0-1) is already installed
-Uvh --oldpackage foo-1.0-1.i386.rpm
Chapter 2. Managing your cluster resources You can apply global configuration options in Red Hat OpenShift Service on AWS. Operators apply these configuration settings across the cluster. 2.1. Interacting with your cluster resources You can interact with cluster resources by using the OpenShift CLI ( oc ) tool in Red Hat OpenShift Service on AWS. The cluster resources that you see after running the oc api-resources command can be edited. Prerequisites You have access to the cluster as a user with the dedicated-admin role. You have access to the web console or you have installed the oc CLI tool. Procedure To see which configuration Operators have been applied, run the following command: USD oc api-resources -o name | grep config.openshift.io To see what cluster resources you can configure, run the following command: USD oc explain <resource_name>.config.openshift.io To see the configuration of custom resource definition (CRD) objects in the cluster, run the following command: USD oc get <resource_name>.config -o yaml To edit the cluster resource configuration, run the following command: USD oc edit <resource_name>.config -o yaml

Commands:
oc api-resources -o name | grep config.openshift.io
oc explain <resource_name>.config.openshift.io
oc get <resource_name>.config -o yaml
oc edit <resource_name>.config -o yaml
2.4. Application Settings for the Data Warehouse service in ovirt-engine-dwhd.conf The following is a list of options for configuring application settings for the Data Warehouse service. These options are available in the /usr/share/ovirt-engine-dwh/services/ovirt-engine-dwhd/ovirt-engine-dwhd.conf file. Configure any changes to the default values in an override file under /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/ . Restart the Data Warehouse service after saving the changes. Table 2.1. ovirt-engine-dwhd.conf application settings variables Variable name Default Value Remarks DWH_DELETE_JOB_HOUR 3 The time at which a deletion job is run. Specify a value between 0 and 23 , where 0 is midnight. DWH_SAMPLING 60 The interval, in seconds, at which data is collected into statistical tables. DWH_TABLES_KEEP_SAMPLES 24 The number of hours that data from DWH_SAMPLING is stored. Data more than two hours old is aggregated into hourly data. DWH_TABLES_KEEP_HOURLY 1440 The number of hours that hourly data is stored. The default is 60 days. Hourly data more than two days old is aggregated into daily data. DWH_TABLES_KEEP_DAILY 43800 The number of hours that daily data is stored. The default is five years. DWH_ERROR_EVENT_INTERVAL 300000 The minimum interval, in milliseconds, at which errors are pushed to the Manager's audit.log .

Commands:
16.3.3. Module Name The module name provides PAM the name of the pluggable module containing the specified module interface. Under older versions of Red Hat Enterprise Linux, the full path to the module was provided within the PAM configuration file, such as /lib/security/pam_stack.so . However, since the advent of multilib systems, which store 64-bit PAM modules within the /lib64/security/ directory, the directory name is omitted because the application is linked to the appropriate version of libpam , which can locate the correct version of the module.

Commands:
Chapter 4. Creating a bucket in your object store To create a bucket in your object store from your workbench, use the create_bucket() method. Prerequisites You have cloned the odh-doc-examples repository to your workbench. You have opened the s3client_examples.ipynb file in your workbench. You have installed Boto3 and configured an S3 client. Procedure In the notebook, locate the following instructions to create a bucket: Replace <name_of_the_bucket> with the name of the bucket that you want to create, as shown in the example, and then run the code cell. The output displays an HTTP response status code of 200 , indicating a successful request. Verification Locate the instructions to list buckets and execute the code cell. The bucket that you created appears in the output.

Commands:
#Create bucket ` s3_client.create_bucket(Bucket='<bucket_name>')
#Create bucket s3_client.create_bucket(Bucket='aqs43-image-registry')
for bucket in s3_client.list_bucket()['Buckets']: print(bucket['Name'])
23.5. Logical Volume Manager LVM provides userspace tools that are used to manage the kernel's DM devices. LVM will shift the start of the data area (that a given DM device will use) to account for a non-zero alignment_offset associated with any device managed by LVM. This means logical volumes will be properly aligned ( alignment_offset=0 ). By default, LVM will adjust for any alignment_offset , but this behavior can be disabled by setting data_alignment_offset_detection to 0 in /etc/lvm/lvm.conf . Disabling this is not recommended. LVM will also detect the I/O hints for a device. The start of a device's data area will be a multiple of the minimum_io_size or optimal_io_size exposed in sysfs. LVM will use the minimum_io_size if optimal_io_size is undefined (i.e. 0 ). By default, LVM will automatically determine these I/O hints, but this behavior can be disabled by setting data_alignment_detection to 0 in /etc/lvm/lvm.conf . Disabling this is not recommended.

Commands:
Chapter 6. Downloading the test plan from Red Hat Certification Portal Note You must download the test plan to the test host. Procedure Log in to Red Hat Certification portal . Search for the case number related to your product certification, and copy it. Click Cases enter the product case number. Optional: Click Test Plans . The test plan displays a list of components that will be tested during the test run. Click Download Test Plan . steps If you plan to use Cockpit to run the tests, see Configuring the systems and running tests by using Cockpit Otherwise, if you plan to use CLI to run the tests, see Configuring the systems and running tests by using CLI .

Commands:
Part III. Migrating to Red Hat build of Kogito microservices As a developer of business decisions and processes, you can migrate your decision services in Red Hat Decision Manager to Red Hat build of Kogito microservices. When performing migration, your existing business decisions become part of your own domain-specific cloud-native set of services. You can migrate Decision Model and Notation (DMN) models, Predictive Model Markup Language (PMML) models, or Drools Rule Language (DRL) rules. Prerequisites JDK 11 or later is installed. Apache Maven 3.6.2 or later is installed.

Commands:
Chapter 2. Architectures Red Hat Enterprise Linux 7.4 is distributed with the kernel version 3.10.0-693, which provides support for the following architectures: [1] 64-bit AMD 64-bit Intel IBM POWER7+ and POWER8 (big endian) [2] IBM POWER8 (little endian) [3] IBM z Systems [4] [1] Note that the Red Hat Enterprise Linux 7.4 installation is supported only on 64-bit hardware. Red Hat Enterprise Linux 7.4 is able to run 32-bit operating systems, including versions of Red Hat Enterprise Linux, as virtual machines. [2] Red Hat Enterprise Linux 7.4 (big endian) is currently supported as a KVM guest on Red Hat Enterprise Virtualization for Power, and on PowerVM. [3] Red Hat Enterprise Linux 7.4 (little endian) is currently supported as a KVM guest on Red Hat Enterprise Virtualization for Power, on PowerVM, and PowerNV (bare metal). [4] Note that Red Hat Enterprise Linux 7.4 supports IBM zEnterprise 196 hardware or later; IBM z10 Systems mainframe systems are no longer supported and will not boot Red Hat Enterprise Linux 7.4.

Commands:
Part VI. Deprecated Functionality This part provides an overview of functionality that has been deprecated in all minor releases up to Red Hat Enterprise Linux 7.6. Deprecated functionality continues to be supported until the end of life of Red Hat Enterprise Linux 7. Deprecated functionality will likely not be supported in future major releases of this product and is not recommended for new deployments. For the most recent list of deprecated functionality within a particular major release, refer to the latest version of release documentation. Deprecated hardware components are not recommended for new deployments on the current or future major releases. Hardware driver updates are limited to security and critical fixes only. Red Hat recommends replacing this hardware as soon as reasonably feasible. A package can be deprecated and not recommended for further use. Under certain circumstances, a package can be removed from a product. Product documentation then identifies more recent packages that offer functionality similar, identical, or more advanced to the one deprecated, and provides further recommendations. For details regarding differences between RHEL 7 and RHEL 8, see Considerations in adopting RHEL 8 .

Commands:
Appendix A. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the AMQ Streams for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Revised on 2022-06-24 09:59:24 UTC

Commands:
Chapter 4. Configuring the LVS Routers with Piranha Configuration Tool The Piranha Configuration Tool provides a structured approach to creating the necessary configuration file for LVS - /etc/sysconfig/ha/lvs.cf . This chapter describes the basic operation of the Piranha Configuration Tool and how to activate LVS once configuration is complete. Important The configuration file for LVS follows strict formatting rules. Using the Piranha Configuration Tool is the best way to prevent syntax errors in the lvs.cf and therefore prevent software failures. 4.1. Necessary Software The piranha-gui service must be running on the primary LVS router to use the Piranha Configuration Tool . To configure LVS, you minimally need a text-only Web browser, such as links . If you are accessing the LVS router from another machine, you also need an ssh connection to the primary LVS router as the root user. While configuring the primary LVS router it is a good idea to keep a concurrent ssh connection in a terminal window. This connection provides a secure way to restart pulse and other services, configure network packet filters, and monitor /var/log/messages during trouble shooting. The four sections walk through each of the configuration pages of the Piranha Configuration Tool and give instructions on using it to set up LVS.

Commands:
8.117. librelp 8.117.1. RHBA-2014:1505 - librelp bug fix and enhancement update Updated librelp packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Librelp is an easy-to-use library for the RELP protocol. RELP (stands for Reliable Event Logging Protocol) is a general-purpose, extensible logging protocol. Note The librelp packages have been upgraded to upstream version 1.2.7, which provides a number of bug fixes and enhancements over the version. (BZ# 966974 ) Users of librelp are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 8. Vault SPI 8.1. Vault provider You can use a vault SPI from org.keycloak.vault package to write custom extension for Red Hat build of Keycloak to connect to arbitrary vault implementation. The built-in files-plaintext provider is an example of the implementation of this SPI. In general the following rules apply: To prevent a secret from leaking across realms, you may want to isolate or limit the secrets that can be retrieved by a realm. In that case, your provider should take into account the realm name when looking up secrets, for example by prefixing entries with the realm name. For example, an expression USD{vault.key} would then evaluate generally to different entry names, depending on whether it was used in a realm A or realm B . To differentiate between realms, the realm needs to be passed to the created VaultProvider instance from VaultProviderFactory.create() method where it is available from the KeycloakSession parameter. The vault provider needs to implement a single method obtainSecret that returns a VaultRawSecret for the given secret name. That class holds the representation of the secret either in byte[] or ByteBuffer and is expected to convert between the two upon demand. Note that this buffer would be discarded after usage as explained below. For details on how to package and deploy a custom provider refer to the Service Provider Interfaces chapter. 8.2. Consuming values from vault The vault contains sensitive data and Red Hat build of Keycloak treats the secrets accordingly. When accessing a secret, the secret is obtained from the vault and retained in JVM memory only for the necessary time. Then all possible attempts to discard its content from JVM memory is done. This is achieved by using the vault secrets only within try -with-resources statement as outlined below: char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage The example uses KeycloakSession.vault() as the entrypoint for accessing the secrets. Using the VaultProvider.obtainSecret method directly is indeed also possible. However the vault() method has the benefit of ability to interpret the raw secret (which is generally a byte array) as a character array (via vault().getCharSecret() ) or a String (via vault().getStringSecret() ) in addition to obtaining the original uninterpreted value (via vault().getRawSecret() method). Note that since String objects are immutable, their content cannot be discarded by overriding with random garbage. Even though measures have been taken in the default VaultStringSecret implementation to prevent internalizing String s, the secrets stored in String objects would live at least to the GC round. Thus using plain byte and character arrays and buffers is preferable.

Commands:
char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage