mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. Runtime Updates 11.1. Data Updates Data change events are used by Red Hat JBoss Data Virtualization to invalidate resultset cache entries. Resultset cache entries are tracked by the tables that contributed to their results. By default, Red Hat JBoss Data Virtualization will capture internal data events against physical sources and distribute them across the cluster. This approach has a couple of limitations. First, updates are scoped only to their originating VDB/version. Second, updates made outside of Red Hat JBoss Data Virtualization are not captured. To increase data consistency, external change data capture tools can be used to send events to Red Hat JBoss Data Virtualization. From within a cluster the org.teiid.events.EventDistributorFactory and org.teiid.events.EventDistributor can be used to distribute change events. The EventDistributorFactory can be looked up by its name "teiid/event-distributor-factory". See the example below. InitialContext ctx = new InitialContext(); EventDistributorFactory edf = (EventDistributorFactory)ctx.lookup("teiid/event-distributor-factory"); EventDistributor ed = edf.getEventDistributor(); ed.dataModification(vdbName, vdbVersion, schema, tableName); This will distribute a change event for schema.tableName in VDB vdbName.vdbVersion. When externally capturing all update events, the "detect-change-events" property in the "teiid" subsystem can be set to false, so change events will not be duplicated. By default, this property is set to true. Use of other EventDistributor methods to manually distribute other events is not always necessary. See System Procedures in Red Hat JBoss Development Guide: Reference Material for SQL based updates. Note Using the org.teiid.events.EventDistributor interface you can also update runtime metadata. Refer to the API.

Commands:
InitialContext ctx = new InitialContext(); EventDistributorFactory edf = (EventDistributorFactory)ctx.lookup("teiid/event-distributor-factory"); EventDistributor ed = edf.getEventDistributor(); ed.dataModification(vdbName, vdbVersion, schema, tableName);
Chapter 3. Using the Red Hat OpenShift Service on AWS dashboard to get cluster information The Red Hat OpenShift Service on AWS web console captures high-level information about the cluster. 3.1. About the Red Hat OpenShift Service on AWS dashboards page Access the Red Hat OpenShift Service on AWS dashboard, which captures high-level information about the cluster, by navigating to Home Overview from the Red Hat OpenShift Service on AWS web console. The Red Hat OpenShift Service on AWS dashboard provides various cluster information, captured in individual dashboard cards. The Red Hat OpenShift Service on AWS dashboard consists of the following cards: Details provides a brief overview of informational cluster details. Status include ok , error , warning , in progress , and unknown . Resources can add custom status names. Cluster ID Provider Version Cluster Inventory details number of resources and associated statuses. It is helpful when intervention is required to resolve problems, including information about: Number of nodes Number of pods Persistent storage volume claims Bare metal hosts in the cluster, listed according to their state (only available in metal3 environment) Status helps administrators understand how cluster resources are consumed. Click on a resource to jump to a detailed page listing pods and nodes that consume the largest amount of the specified cluster resource (CPU, memory, or storage). Cluster Utilization shows the capacity of various resources over a specified period of time, to help administrators understand the scale and frequency of high resource consumption, including information about: CPU time Memory allocation Storage consumed Network resources consumed Pod count Activity lists messages related to recent activity in the cluster, such as pod creation or virtual machine migration to another host. 3.2. Recognizing resource and project limits and quotas You can view a graphical representation of available resources in the Topology view of the web console Developer perspective. If a resource has a message about resource limitations or quotas being reached, a yellow border appears around the resource name. Click the resource to open a side panel to see the message. If the Topology view has been zoomed out, a yellow dot indicates that a message is available. If you are using List View from the View Shortcuts menu, resources appear as a list. The Alerts column indicates if a message is available.

Commands:
Chapter 40. Clustering The pcs tool now manages bundle resources in Pacemaker As a Technology Preview starting with Red Hat Enterprise Linux 7.4, the pcs tool supports bundle resources. You can now use the pcs resource bundle create and the pcs resource bundle update commands to create and modify a bundle. You can add a resource to an existing bundle with the pcs resource create command. For information on the parameters you can set for a bundle resource, run the pcs resource bundle --help command. (BZ# 1433016 ) New fence-agents-heuristics-ping fence agent As a Technology Preview, Pacemaker now supports the fence_heuristics_ping agent. This agent aims to open a class of experimental fence agents that do no actual fencing by themselves but instead exploit the behavior of fencing levels in a new way. If the heuristics agent is configured on the same fencing level as the fence agent that does the actual fencing but is configured before that agent in sequence, fencing issues an off action on the heuristics agent before it attempts to do so on the agent that does the fencing. If the heuristics agent gives a negative result for the off action it is already clear that the fencing level is not going to succeed, causing Pacemaker fencing to skip the step of issuing the off action on the agent that does the fencing. A heuristics agent can exploit this behavior to prevent the agent that does the actual fencing from fencing a node under certain conditions. A user might want to use this agent, especially in a two-node cluster, when it would not make sense for a node to fence the peer if it can know beforehand that it would not be able to take over the services properly. For example, it might not make sense for a node to take over services if it has problems reaching the networking uplink, making the services unreachable to clients, a situation which a ping to a router might detect in that case. (BZ#1476401) Heuristics supported in corosync-qdevice as a Technology Preview Heuristics are a set of commands executed locally on startup, cluster membership change, successful connect to corosync-qnetd , and, optionally, on a periodic basis. When all commands finish successfully on time (their return error code is zero), heuristics have passed; otherwise, they have failed. The heuristics result is sent to corosync-qnetd where it is used in calculations to determine which partition should be quorate. (BZ# 1413573 , BZ# 1389209 )

Commands:
5.38. crash-trace-command 5.38.1. RHBA-2012:0808 - crash-trace-command bug fix update An updated crash-trace-command package that fixes one bug is now available for Red Hat Enterprise Linux 6. The crash-trace-command package provides a trace extension module for the crash utility, allowing it to read ftrace data from a core dump file. Bug Fix BZ# 729018 Previously, the "trace.so" binary in the crash-trace-command package was compiled by the GCC compiler without the "-g" option. Therefore, no debugging information was included in its associated "trace.so.debug" file. This could affect a crash analysis performed by the Automatic Bug Reporting Tool (ABRT) and its retrace server. Also, proper debugging of crashes using the GDB utility was not possible under these circumstances. This update modifies the Makefile of crash-trace-command to compile the "trace.so" binary with the "RPM_OPT_FLAGS" flag, which ensures that the GCC's "-g" option is used during the compilation. Debugging and a crash analysis can now be performed as expected. All users of crash-trace-command are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 1. Ansible development tools Ansible development tools ( ansible-dev-tools ) is a suite of tools provided with Ansible Automation Platform to help automation creators to create, test, and deploy playbook projects, execution environments, and collections. The Ansible VS Code extension by Red Hat integrates most of the Ansible development tools: you can use these tools from the VS Code user interface. Use Ansible development tools during local development of playbooks, local testing, and in a CI pipeline (linting and testing). This document describes how to use Ansible development tools to create a playbook project that contains playbooks and roles that you can reuse within the project. It also describes how to test the playbooks and deploy the project on your {AAP} instance so that you can use the playbooks in automation jobs. 1.1. Ansible development tools components You can operate some Ansible development tools from the VS Code UI when you have installed the Ansible extension, and the remainder from the command line. VS Code is a free open-source code editor available on Linux, Mac, and Windows. Ansible VS Code extension This is not packaged with the Ansible Automation Platform RPM package, but it is an integral part of the automation creation workflow. From the VS Code UI, you can use the Ansible development tools for the following tasks: Scaffold directories for a playbook project or a collection. Write playbooks with the help of syntax highlighting and auto-completion. Debug your playbooks with a linter. Execute playbooks with Ansible Core using ansible-playbook . Execute playbooks in an execution environment with ansible-navigator . From the VS Code extension, you can also connect to Red Hat Ansible Lightspeed with IBM watsonx Code Assistant. Command-line Ansible development tools You can perform the following tasks with Ansible development tools from the command line, including the terminal in VS Code: Create an execution environment. Test your playbooks, roles, modules, plugins and collections.

Commands:
4.4. Cache Entry Expiration Behavior Red Hat JBoss Data Grid does not guarantee that an entry is removed immediately upon timeout. Instead, a number of mechanisms are used in collaboration to ensure efficient removal. An expired entry is removed from the cache when either: An entry is passivated/overflowed to disk and is discovered to have expired. The expiration maintenance thread discovers that an entry it has found is expired. If a user requests an entry that is expired but not yet removed, a null value is sent to the user. This mechanism ensures that the user never receives an expired entry. The entry is eventually removed by the expiration thread. Report a bug

Commands:
Chapter 1. Overview AMQ JMS Pool is a library that provides caching of JMS connections, sessions, and message producers. It enables reuse of connection resources beyond the standard lifecycle defined by the JMS API. AMQ JMS Pool operates as a standard JMS ConnectionFactory instance that wraps the ConnectionFactory of your chosen JMS provider and manages the lifetime of Connection objects from that provider based on the configuration of the JMS pool. It can be configured to share one or more connections among callers to the pool createConnection() methods. AMQ JMS Pool is part of AMQ Clients, a suite of messaging libraries supporting multiple languages and platforms. For an overview of the clients, see AMQ Clients Overview . For information about this release, see AMQ Clients 2.10 Release Notes . AMQ JMS Pool is based on the Pooled JMS messaging library. 1.1. Key features JMS 1.1 and 2.0 compatible Automatic reconnect Configurable connection and session pool sizes 1.2. Supported standards and protocols AMQ JMS Pool supports version 2.0 of the Java Message Service API. 1.3. Supported configurations Refer to Red Hat AMQ 7 Supported Configurations on the Red Hat Customer Portal for current information regarding AMQ JMS Pool supported configurations. 1.4. Document conventions The sudo command In this document, sudo is used for any command that requires root privileges. Exercise caution when using sudo because any changes can affect the entire system. For more information about sudo , see Using the sudo command . File paths In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/andrea ). On Microsoft Windows, you must use the equivalent Windows paths (for example, C:\Users\andrea ). Variable text This document contains code blocks with variables that you must replace with values specific to your environment. Variable text is enclosed in arrow braces and styled as italic monospace. For example, in the following command, replace <project-dir> with the value for your environment: USD cd <project-dir>

Commands:
cd <project-dir>
7.123. man-pages-overrides 7.123.1. RHBA-2015:1295 - man-pages-overrides bug fix update An updated man-pages-overrides package that fixes several bugs is now available for Red Hat Enterprise Linux 6. The man-pages-overrides package provides a collection of manual (man) pages to complement other packages or update those contained therein. Bug Fixes BZ# 1205351 Previously, the eventfd(2) manual page did not describe the EFD_SEMAPHORE flag, although the kernel supported this feature. This update adds the missing details about EFD_SEMAPHORE to eventfd(2). BZ# 1207200 The yum-security(8) manual page contained insufficient information about package selection mechanism of the "update-minimum" command with the "--advisory" option. This update adds a more detailed explanation of this process, including an example syntax. BZ# 1140473 Previously, the description of the %util field in the iostat(1) and sar(1) manual pages was incorrect. The description of %util has been fixed, and documentation of the iostat and sar commands is now correct. BZ# 1205377 The pthread_kill(3) manual page contained incorrect information about a possibility to use the pthread_kill() function to check for the existence of a thread ID. Consequently, following this instruction led to a segmentation fault in case of a non-existent thread ID. The misleading piece of information has been removed and pthread_kill(3) now includes more details about handling of non-existent thread IDs. BZ# 1159335 Previously, the statfs struct section in the statfs(2) manual page did not mention the "f_flags" and "f_spare" fields. This update adds the missing fields to statfs(2). BZ# 1121700 The reposync(1) manual page did not contain descriptions of the "e", "d", "m", and "norepopath" options. With this update, reposync(1) provides the complete list of options and their descriptions. BZ# 1159842 Prior to this update, certain manual pages in Russian language were incorrectly encoded. As a consequence, users were unable to read such man pages. This bug has been fixed, and man pages are displayed in the correct encoding. Users of man-pages-overrides are advised to upgrade to this updated package, which fixes these bugs.

Commands:
4.358. xorg-x11-server 4.358.1. RHBA-2011:1816 - xorg-x11-server bug fix update Updated xorg-x11-server packages that fix one bug are now available for Red Hat Enterprise Linux 6. X.Org is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces are designed upon. Bug Fix BZ# 759022 Previously, a bug in Xephyr's input handling code disabled screens on a screen crossing event. When the Xephyr nested X server was configured in a multi-screen setup, the focus was only on the screen where the mouse was located, and only this screen was updated. The aforementioned code has been removed and the Xephyr server now correctly updates screens in multi-screen setups. All users of xorg-x11-server are advised to upgrade to these updated packages, which fix this bugs. 4.358.2. RHBA-2012:0368 - xorg-x11-server bug fix update Updated xorg-x11-server packages that fix one bug are now available for Red Hat Enterprise Linux 6. X.Org is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces are designed upon. Bug Fix BZ# 783505 Previously, if the X server was configured as a multi-screen setup through multiple "Device" sections in the xorg.conf file, an absolute input device (for example a graphic tablet's stylus) got stuck in the right-most or bottom-most screen. This update changes the screen crossing behavior so that absolute devices are always mapped across all screens. All users of xorg-x11-server are advised to upgrade to these updated packages, which fix this bug.

Commands:
1.3.2.2. Inattentive Administration Administrators who fail to patch their systems are one of the greatest threats to server security. According to the SysAdmin, Audit, Network, Security Institute ( SANS ), the primary cause of computer security vulnerability is to "assign untrained people to maintain security and provide neither the training nor the time to make it possible to do the job. This applies as much to inexperienced administrators as it does to overconfident or amotivated administrators. Some administrators fail to patch their servers and workstations, while others fail to watch log messages from the system kernel or network traffic. Another common error is when default passwords or keys to services are left unchanged. For example, some databases have default administration passwords because the database developers assume that the system administrator changes these passwords immediately after installation. If a database administrator fails to change this password, even an inexperienced attacker can use a widely-known default password to gain administrative privileges to the database. These are only a few examples of how inattentive administration can lead to compromised servers.

Commands:
20.11. Service Level Agreement Policy Enforcement This procedure describes how to set service level agreement CPU features. Setting a Service Level Agreement CPU Policy Click Compute Virtual Machines . Click New , or select a virtual machine and click Edit . Click the Resource Allocation tab. Specify CPU Shares . Possible options are Low , Medium , High , Custom , and Disabled . Virtual machines set to High receive twice as many shares as Medium , and virtual machines set to Medium receive twice as many shares as virtual machines set to Low . Disabled instructs VDSM to use an older algorithm for determining share dispensation; usually the number of shares dispensed under these conditions is 1020. The CPU consumption of users is now governed by the policy you have set.

Commands:
23.4. Using the PTP Management Client The PTP management client, pmc , can be used to obtain additional information from ptp4l as follows: Setting the -b option to zero limits the boundary to the locally running ptp4l instance. A larger boundary value will retrieve the information also from PTP nodes further from the local clock. The retrievable information includes: stepsRemoved is the number of communication paths to the grandmaster clock. offsetFromMaster and master_offset is the last measured offset of the clock from the master in nanoseconds. meanPathDelay is the estimated delay of the synchronization messages sent from the master in nanoseconds. if gmPresent is true, the PTP clock is synchronized to a master, the local clock is not the grandmaster clock. gmIdentity is the grandmaster's identity. For a full list of pmc commands, type the following as root : Additional information is available in the pmc(8) man page.

Commands:
~]# pmc -u -b 0 'GET CURRENT_DATA_SET' sending: GET CURRENT_DATA_SET 90e2ba.fffe.20c7f8-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET stepsRemoved 1 offsetFromMaster -142.0 meanPathDelay 9310.0
~]# pmc -u -b 0 'GET TIME_STATUS_NP' sending: GET TIME_STATUS_NP 90e2ba.fffe.20c7f8-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP master_offset 310 ingress_time 1361545089345029441 cumulativeScaledRateOffset +1.000000000 scaledLastGmPhaseChange 0 gmTimeBaseIndicator 0 lastGmPhaseChange 0x0000'0000000000000000.0000 gmPresent true gmIdentity 00a069.fffe.0b552d
~]# pmc help
2.3. Built-in Command-Line Tools Red Hat Enterprise Linux 7 provides several tools that can be used to monitor your system from the command line, allowing you to monitor your system outside run level 5. This chapter discusses each tool briefly and provides links to further information about where each tool should be used, and how to use them. 2.3.1. top The top tool, provided by the procps-ng package, gives a dynamic view of the processes in a running system. It can display a variety of information, including a system summary and a list of tasks currently being managed by the Linux kernel. It also has a limited ability to manipulate processes, and to make configuration changes persistent across system restarts. By default, the processes displayed are ordered according to the percentage of CPU usage, so that you can easily see the processes consuming the most resources. Both the information top displays and its operation are highly configurable to allow you to concentrate on different usage statistics as required. For detailed information about using top, see the man page: 2.3.2. ps The ps tool, provided by the procps-ng package, takes a snapshot of a select group of active processes. By default, the group examined is limited to processes that are owned by the current user and associated with the terminal in which ps is run. ps can provide more detailed information about processes than top, but by default it provides a single snapshot of this data, ordered by process identifier. For detailed information about using ps, see the man page: 2.3.3. Virtual Memory Statistics (vmstat) The Virtual Memory Statistics tool, vmstat, provides instant reports on your system's processes, memory, paging, block input/output, interrupts, and CPU activity. Vmstat lets you set a sampling interval so that you can observe system activity in near-real time. vmstat is provided by the procps-ng package. For detailed information about using vmstat, see the man page: 2.3.4. System Activity Reporter (sar) The System Activity Reporter, sar, collects and reports information about system activity that has occurred so far on the current day. The default output displays the current day's CPU usage at 10 minute intervals from the beginning of the day (00:00:00 according to your system clock). You can also use the -i option to set the interval time in seconds, for example, sar -i 60 tells sar to check CPU usage every minute. sar is a useful alternative to manually creating periodic reports on system activity with top. It is provided by the sysstat package. For detailed information about using sar, see the man page:

Commands:
man top
man ps
man vmstat
man sar