mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Differences from upstream OpenJDK 8 Red Hat build of OpenJDK in Red Hat Enterprise Linux (RHEL) contains a number of structural changes from the upstream distribution of OpenJDK. The Microsoft Windows version of Red Hat build of OpenJDK attempts to follow RHEL updates as closely as possible. The following list details the most notable Red Hat build of OpenJDK 8 changes: FIPS support. Red Hat build of OpenJDK 8 automatically detects whether RHEL is in FIPS mode and automatically configures Red Hat build of OpenJDK 8 to operate in that mode. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows. Cryptographic policy support. Red Hat build of OpenJDK 8 obtains the list of enabled cryptographic algorithms and key size constraints from the RHEL system configuration. These configuration components are used by the Transport Layer Security (TLS) encryption protocol, the certificate path validation, and any signed JARs. You can set different security profiles to balance safety and compatibility. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows. Red Hat build of OpenJDK on RHEL dynamically links against native libraries such as zlib for archive format support and libjpeg-turbo , libpng , and giflib for image support. RHEL also dynamically links against Harfbuzz and Freetype for font rendering and management. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows. The src.zip file includes the source for all the JAR libraries shipped with Red Hat build of OpenJDK. Red Hat build of OpenJDK on RHEL uses system-wide timezone data files as a source for timezone information. Red Hat build of OpenJDK on RHEL uses system-wide CA certificates. Red Hat build of OpenJDK on Microsoft Windows includes the latest available timezone data from RHEL. Red Hat build of OpenJDK on Microsoft Windows uses the latest available CA certificate from RHEL. Additional resources See, Improve system FIPS detection (RHEL Planning Jira) See, Using system-wide cryptographic policies (RHEL documentation)

Commands:
17.3. Shared Cache Stores A shared cache store is a cache store that is shared by multiple cache instances. A shared cache store is useful when all instances in a cluster communicate with the same remote, shared database using the same JDBC settings. In such an instance, configuring a shared cache store prevents the unnecessary repeated write operations that occur when various cache instances attempt to write the same data to the cache store. Report a bug 17.3.1. Invalidation Mode and Shared Cache Stores When used in conjunction with a shared cache store, Red Hat JBoss Data Grid's invalidation mode causes remote caches to see the shared cache store to retrieve modified data. The benefits of using invalidation mode in conjunction with shared cache stores include the following: Compared to replication messages, which contain the updated data, invalidation messages are much smaller and result in reduced network traffic. The remaining cluster caches look up modified data from the shared cache store lazily and only when required to do so, resulting in further reduced network traffic. Report a bug 17.3.2. The Cache Store and Cache Passivation In Red Hat JBoss Data Grid, a cache store can be used to enforce the passivation of entries and to activate eviction in a cache. Whether passivation mode or activation mode are used, the configured cache store both reads from and writes to the data store. When passivation is disabled in JBoss Data Grid, after the modification, addition or removal of an element is carried out the cache store steps in to persist the changes in the store. Report a bug 17.3.3. Application Cachestore Registration It is not necessary to register an application cache store for an isolated deployment. This is not a requirement in Red Hat JBoss Data Grid because lazy deserialization is used to work around this problem. Report a bug

Commands:
3.8. Backing Up and Restoring a Cluster Configuration As of the Red Hat Enterprise Linux 7.1 release, you can back up the cluster configuration in a tarball with the following command. If you do not specify a file name, the standard output will be used. Use the following command to restore the cluster configuration files on all cluster nodes from the backup. Specifying the --local option restores the cluster configuration files only on the node from which you run this command. If you do not specify a file name, the standard input will be used.

Commands:
pcs config backup filename
pcs config restore [--local] [ filename ]
Chapter 61. BrokerCapacity schema reference Used in: CruiseControlSpec Property Property type Description disk string The disk property has been deprecated. The Cruise Control disk capacity setting has been deprecated, is ignored, and will be removed in the future Broker capacity for disk in bytes. Use a number value with either standard OpenShift byte units (K, M, G, or T), their bibyte (power of two) equivalents (Ki, Mi, Gi, or Ti), or a byte value with or without E notation. For example, 100000M, 100000Mi, 104857600000, or 1e+11. cpuUtilization integer The cpuUtilization property has been deprecated. The Cruise Control CPU capacity setting has been deprecated, is ignored, and will be removed in the future Broker capacity for CPU resource utilization as a percentage (0 - 100). cpu string Broker capacity for CPU resource in cores or millicores. For example, 1, 1.500, 1500m. For more information on valid CPU resource units see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu . inboundNetwork string Broker capacity for inbound network throughput in bytes per second. Use an integer value with standard OpenShift byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s. outboundNetwork string Broker capacity for outbound network throughput in bytes per second. Use an integer value with standard OpenShift byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s. overrides BrokerCapacityOverride array Overrides for individual brokers. The overrides property lets you specify a different capacity configuration for different brokers.

Commands:
F.7. Project Menu Figure F.9. Project Menu The individual actions in the Project menu are described below: Open Project - Launches the Open Project dialog. Close Project - Closes the currently selected project(s). Build All - Validates the contents of the entire workspace. Any errors or warnings will appear in the Problems View. Build Project - Validates the contents of the selected project(s). Any errors or warnings will appear in the Problems View. Build Working Set - Validates the contents of the selected working set. Any errors or warnings will appear in the Problems View. Clean.. - Launches the Clean dialog. Build Automatically - Sets the Build Automatically flag on or off. When on, a checkmark appears to the left of this menu item. When this is turned on, validation of changes is done automatically each time a Save is done. Clone Project - Launches the Clone Project dialog. Build Project Imports - Reconciles all model import dependencies for models contained within the selected project. Build All Imports - Reconciles all model import dependencies for models contained within the workspace. Build Packages - TBD Validate Model Transformations - Revalidates all transformations for the selected view model. Properties - Displays the operating system's file properties dialog for the selected file.

Commands:
Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. To propose improvements, open a Jira issue and describe your suggested changes. Provide as much detail as possible to enable us to address your request quickly. Prerequisite You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one. Procedure Click the following: Create issue . In the Summary text box, enter a brief description of the issue. In the Description text box, provide the following information: The URL of the page where you found the issue. A detailed description of the issue. You can leave the information in any other fields at their default values. Add a reporter name. Click Create to submit the Jira issue to the documentation team. Thank you for taking the time to provide feedback.

Commands:
REST API Guide Red Hat Virtualization 4.4 Using the Red Hat Virtualization REST Application Programming Interface Red Hat Virtualization Documentation Team rhev-docs@redhat.com Abstract This guide describes the Red Hat Virtualization Manager Representational State Transfer Application Programming Interface. This guide is generated from documentation comments in the ovirt-engine-api-model code, and is currently partially complete. Updated versions of this documentation will be published as new content becomes available.

Commands:
Chapter 16. Conduits Abstract Conduits are a low-level piece of the transport architecture that are used to implement outbound connections. Their behavior and life-cycle can effect system performance and processing load. Overview Conduits manage the client-side, or outbound, transport details in the Apache CXF runtime. They are responsible for opening ports, establishing outbound connections, sending messages, and listening for any responses between an application and a single external endpoint. If an application connects to multiple endpoints, it will have one conduit instance for each endpoint. Each transport type implements its own conduit using the Conduit interface. This allows for a standardized interface between the application level functionality and the transports. In general, you only need to worry about the conduits being used by your application when configuring the client-side transport details. The underlying semantics of how the runtime handles conduits is, generally, not something a developer needs to worry about. However, there are cases when an understanding of conduit's can prove helpful: Implementing a custom transport Advanced application tuning to manage limited resources Conduit life-cycle Conduits are managed by the client implementation object. Once created, a conduit lives for the duration of the client implementation object. The conduit's life-cycle is: When the client implementation object is created, it is given a reference to a ConduitSelector object. When the client needs to send a message is request's a reference to a conduit from the conduit selector. If the message is for a new endpoint, the conduit selector creates a new conduit and passes it to the client implementation. Otherwise, it passes the client a reference to the conduit for the target endpoint. The conduit sends messages when needed. When the client implementation object is destroyed, all of the conduits associated with it are destroyed. Conduit weight The weight of a conduit object depends on the transport implementation. HTTP conduits are extremely light weight. JMS conduits are heavy because they are associated with the JMS Session object and one or more JMSListenerContainer objects.

Commands:
7.8. automake 7.8.1. RHSA-2013:0526 - Low: automake security update An updated automake package that fixes one security issue is now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having low security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Automake is a tool for automatically generating Makefile.in files compliant with the GNU Coding Standards. Security Fix CVE-2012-3386 It was found that the distcheck rule in Automake-generated Makefiles made a directory world-writable when preparing source archives. If a malicious, local user could access this directory, they could execute arbitrary code with the privileges of the user running "make distcheck". Red Hat would like to thank Jim Meyering for reporting this issue. Upstream acknowledges Stefano Lattarini as the original reporter. Users of automake are advised to upgrade to this updated package, which corrects this issue.

Commands:
7.4. RHEA-2013:1626 - new packages: p11-kit New p11-kit packages are now available for Red Hat Enterprise Linux 6. The p11-kit package provides a mechanism to manage PKCS#11 modules. The p11-kit-trust subpackage includes a PKCS#11 trust module that provides certificate anchors and black lists based on configuration files. This enhancement update adds the p11-kit packages to Red Hat Enterprise Linux 6. (BZ# 915798 ) * Red Hat Enterprise Linux 6.5 provides the p11-kit package to implement the Shared System Certificates feature. If enabled by the administrator, it ensures system-wide trust store of static data that is used by crypto toolkits as input for certificate trust decisions. (BZ# 977886 ) These new packages had several bugs fixed during testing: * Support for using the freebl3 library for the SHA1 and MD5 cryptographic hash functions has been added even though the hashing is done in a strictly non-cryptographic context. (BZ# 983384 ) * All file handles opened by p11-kit are created with the O_CLOEXEC flag, so that they are automatically closed on the execve() function and do not leak to subprocesses. (BZ# 984986 ) * When expanding the "USDHOME" variable or the "~/" path for SUID and SGID programs, the expand_home() function returns NULL. This change allows for avoiding vulnerabilities that could occur if SUID or SGID programs accidentally trusted this environment. Also, documentation concerning the fact that user directories are not read for SUID/SGID programs has been added. (BZ# 985014 ) * Users need to use the standard environment USDTMPDIR variable for locating the temp directory. (BZ# 985017 ) * If a critical module fails to initialize, module initialization stops and the user is informed about the failure. (BZ# 985023 ) * The p11_kit_space_strlen() function returns a "0" value for empty strings. (BZ# 985416 ) * Arguments of the size_t variable are correctly passed to the "p11_hash_xxx" functions. (BZ# 985421 ) * Changes in the code ensures that the memdup() function is not called with a zero length or NULL pointers. (BZ# 985433 ) All users who require the Shared System Certificates feature are advised to install these new packages.

Commands:
2.8. Performance Issues: Check the Red Hat Customer Portal For information on best practices for deploying and upgrading Red Hat Enterprise Linux clusters using the High Availability Add-On and Red Hat Global File System 2 (GFS2) see the article "Red Hat Enterprise Linux Cluster, High Availability, and GFS Deployment Best Practices" on Red Hat Customer Portal at https://access.redhat.com/site/articles/40051 .

Commands:
11.2.2. Creating an LVM2 Logical Volume for Swap To add a swap volume group (assuming /dev/VolGroup00/LogVol02 is the swap volume you want to add): Create the LVM2 logical volume of size 256 MB: Format the new swap space: Add the following entry to the /etc/fstab file: Enable the extended logical volume: Test that the logical volume has been extended properly:

Commands:
lvm lvcreate VolGroup00 -n LogVol02 -L 256M
mkswap /dev/VolGroup00/LogVol02
/dev/VolGroup00/LogVol02 swap swap defaults 0 0
swapon -va
cat /proc/swaps # free
2.6. GRUB Commands GRUB allows a number of useful commands in its command line interface. Some of the commands accept options after their name; these options should be separated from the command and other options on that line by space characters. The following is a list of useful commands: boot - Boots the operating system or chain loader that was last loaded. chainloader </path/to/file> - Loads the specified file as a chain loader. If the file is located on the first sector of the specified partition, use the blocklist notation, +1 , instead of the file name. The following is an example chainloader command: displaymem - Displays the current use of memory, based on information from the BIOS. This is useful to determine how much RAM a system has prior to booting it. initrd </path/to/initrd> - Enables users to specify an initial RAM disk to use when booting. An initrd is necessary when the kernel needs certain modules in order to boot properly, such as when the root partition is formatted with the ext3 file system. The following is an example initrd command: install <stage-1> <install-disk> <stage-2> p config-file - Installs GRUB to the system MBR. <stage-1> - Signifies a device, partition, and file where the first boot loader image can be found, such as (hd0,0)/grub/stage1 . <install-disk> - Specifies the disk where the stage 1 boot loader should be installed, such as (hd0) . <stage-2> - Passes the stage 2 boot loader location to the stage 1 boot loader, such as (hd0,0)/grub/stage2 . p <config-file> - This option tells the install command to look for the menu configuration file specified by <config-file> , such as (hd0,0)/grub/grub.conf . Warning The install command overwrites any information already located on the MBR. kernel </path/to/kernel> <option-1> <option-N> ... - Specifies the kernel file to load when booting the operating system. Replace </path/to/kernel> with an absolute path from the partition specified by the root command. Replace <option-1> with options for the Linux kernel, such as root=/dev/VolGroup00/LogVol00 to specify the device on which the root partition for the system is located. Multiple options can be passed to the kernel in a space separated list. The following is an example kernel command: The option in the example specifies that the root file system for Linux is located on the hda5 partition. root ( <device-type> <device-number> , <partition> ) - Configures the root partition for GRUB, such as (hd0,0) , and mounts the partition. The following is an example root command: rootnoverify ( <device-type> <device-number> , <partition> ) - Configures the root partition for GRUB, just like the root command, but does not mount the partition. Other commands are also available; type help --all for a full list of commands. For a description of all GRUB commands, refer to the documentation available online at http://www.gnu.org/software/grub/manual/ .

Commands:
chainloader +1
initrd /initrd-2.6.8-1.523.img
kernel /vmlinuz-2.6.8-1.523 ro root=/dev/VolGroup00/LogVol00
root (hd0,0)
Chapter 12. Translators 12.1. JBoss Data Virtualization Connector Architecture The process of integrating data from an enterprise information system into JBoss Data Virtualization requires one to two components: a translator (mandatory) and a resource adapter (optional), also known as a connector. Most of the time, this will be a Java EE Connector Architecture (JCA) Adapter. A translator is used to: translate JBoss Data Virtualization commands into commands understood by the datasource for which the translator is being used, execute those commands, return batches of results from the datasource, translated into the formats that JBoss Data Virtualization is expecting. A resource adapter (or connector): handles all communications with individual enterprise information systems, (which can include databases, data feeds, flat files and so forth), can be a JCA Adapter or any other custom connection provider (the JCA specification ensures the writing, packaging and configuration are undertaken in a consistent manner), Note Many software vendors provide JCA Adapters to access different systems. Red Hat recommends using vendor-supplied JCA Adapters when using JMS with JCA. See http://docs.oracle.com/cd/E21764_01/integration.1111/e10231/adptr_jms.htm removes concerns such as connection information, resource pooling, and authentication for translators. With a suitable translator (and optional resource adapter), any datasource or Enterprise Information System can be integrated with JBoss Data Virtualization.

Commands:
5.4. Optimizing the Query Process Query performance depends on several criteria: The Lucene query. The number of objects loaded: use pagination or index projection where required. The way the Query Module interacts with the Lucene readers defines the appropriate reader strategy. Caching frequently extracted values from the index. Report a bug 5.4.1. Caching Index Values: FieldCache The Lucene index identifies matches to queries. Once the query is performed the results must be analyzed to extract useful information. The Lucene-based Query API is used to extract the Class type and the primary key. Extracting the required values from the index reduces performance. In some cases this may be minor, other cases may require caching. Requirements depend on the kind of projections being used and in some cases the Class type is not required. The @CacheFromIndex annotation is used to perform caching on the main metadata fields required by the Lucene-based Query API. Example 5.28. The @CacheFromIndex Annotation It is possible to cache Class types and IDs using this annotation: CLASS : The Query Module uses a Lucene FieldCache to improve performance of the Class type extraction from the index. This value is enabled by default. The Lucene-based Query API applies this value when the @CacheFromIndex annotation is not specified. ID : Extracting the primary identifier uses a cache. This method produces the best querying results, however it may reduce performance. Note Measure the performance and memory consumption impact after warmup (executing some queries). Performance may improve by enabling Field Caches but this is not always the case. Using a FieldCache has following two disadvantages: Memory usage: Typically the CLASS cache has lower requirements than the ID cache. Index warmup: When using field caches, the first query on a new index or segment is slower than when caching is disabled. Some queries may not require a classtype, and ignore the CLASS field cache even when enabled. For example, when targeting a single class, all returned values are of that type. The ID FieldCache requires the ids of targeted entities to be using a TwoWayFieldBridge . All types being loaded in a specific query must use the fieldname for the id and have ids of the same type. This is evaluated at query execution. Report a bug

Commands:
import static org.hibernate.search.annotations.FieldCacheType.CLASS; import static org.hibernate.search.annotations.FieldCacheType.ID; @Indexed @CacheFromIndex( { CLASS, ID } ) public class Essay {
probe::ioscheduler_trace.unplug_io Name probe::ioscheduler_trace.unplug_io - Fires when a request queue is unplugged; Synopsis ioscheduler_trace.unplug_io Values name Name of the probe point rq_queue request queue Description Either, when number of pending requests in the queue exceeds threshold or, upon expiration of timer that was activated when queue was plugged.

Commands:
probe::nfs.aop.write_end Name probe::nfs.aop.write_end - NFS client complete writing data Synopsis nfs.aop.write_end Values sb_flag super block flags __page the address of page page_index offset within mapping, can used a page identifier and position identifier in the page frame to end address of this write operation ino inode number i_flag file flags size write bytes dev device identifier offset start address of this write operation i_size file length in bytes Description Fires when do a write operation on nfs, often after prepare_write Update and possibly write a cached page of an NFS file.

Commands: