mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Using the API For more information, see the Rhea API reference , Rhea example suite and Rhea examples . 5.1. Handling messaging events Red Hat build of Rhea is an asynchronous event-driven API. To define how the application handles events, the user registers event-handling functions on the container object. These functions are then called as network activity or timers trigger new events. Example: Handling messaging events var rhea = require("rhea"); var container = rhea.create_container(); container.on("sendable", function (event) { console.log("A message can be sent"); }); container.on("message", function (event) { console.log("A message is received"); }); These are only a few common-case events. The full set is documented in the Rhea API reference . 5.2. Accessing event-related objects The event argument has attributes for accessing the object the event is regarding. For example, the connection_open event sets the event connection attribute. In addition to the primary object for the event, all objects that form the context for the event are set as well. Attributes with no relevance to a particular event are null. Example: Accessing event-related objects event. container event. connection event. session event. sender event. receiver event. delivery event. message 5.3. Creating a container The container is the top-level API object. It is the entry point for creating connections, and it is responsible for running the main event loop. It is often constructed with a global event handler. Example: Creating a container var rhea = require("rhea"); var container = rhea.create_container(); 5.4. Setting the container identity Each container instance has a unique identity called the container ID. When Red Hat build of Rhea makes a network connection, it sends the container ID to the remote peer. To set the container ID, pass the id option to the create_container method. Example: Setting the container identity var container = rhea.create_container( {id: "job-processor-3"} ); If the user does not set the ID, the library will generate a UUID when the container is constructed.

Commands:
var rhea = require("rhea"); var container = rhea.create_container(); container.on("sendable", function (event) { console.log("A message can be sent"); }); container.on("message", function (event) { console.log("A message is received"); });
event. container event. connection event. session event. sender event. receiver event. delivery event. message
var rhea = require("rhea"); var container = rhea.create_container();
var container = rhea.create_container( {id: "job-processor-3"} );
28.4. Configuring Persistent Memory for use in Device DAX mode Device DAX ( devdax ) provides a means for applications to directly access storage, without the involvement of a file system. The benefit of device DAX is that it provides a guaranteed fault granularity, which can be configured using the --align option with the ndctl utility: The given command ensures that the operating system would fault in 2MiB pages at a time. For the Intel 64 and AMD64 architecture, the following fault granularities are supported: 4KiB 2MiB 1GiB Device DAX nodes ( /dev/dax N.M ) only supports the following system call: open() close() mmap() fallocate() read() and write() variants are not supported because the use case is tied to persistent memory programming.

Commands:
ndctl create-namespace --force --reconfig= namespace0.0 --mode=devdax --align= 2M
Chapter 43. Hardware Enablement LSI Syncro CS HA-DAS adapters Red Hat Enterprise Linux 7.1 included code in the megaraid_sas driver to enable LSI Syncro CS high-availability direct-attached storage (HA-DAS) adapters. While the megaraid_sas driver is fully supported for previously enabled adapters, the use of this driver for Syncro CS is available as a Technology Preview. Support for this adapter is provided directly by LSI, your system integrator, or system vendor. Users deploying Syncro CS on Red Hat Enterprise Linux 7.2 and later are encouraged to provide feedback to Red Hat and LSI. (BZ#1062759) tss2 enables TPM 2.0 for IBM Power LE The tss2 package adds IBM implementation of a Trusted Computing Group Software Stack (TSS) 2.0 as a Technology Preview for the IBM Power LE architecture. This package enables users to interact with TPM 2.0 devices. (BZ#1384452) ibmvnic Device Driver Starting with Red Hat Enterprise Linux 7.3, the ibmvnic Device Driver has been available as a Technology Preview for IBM POWER architectures. vNIC (Virtual Network Interface Controller) is a PowerVM virtual networking technology that delivers enterprise capabilities and simplifies network management. It is a high-performance, efficient technology that when combined with SR-IOV NIC provides bandwidth control Quality of Service (QoS) capabilities at the virtual NIC level. vNIC significantly reduces virtualization overhead, resulting in lower latencies and fewer server resources, including CPU and memory, required for network virtualization. (BZ# 1391561 , BZ#947163)

Commands:
8.2.3.2. Incremental Backups Unlike full backups, incremental backups first look to see whether a file's modification time is more recent than its last backup time. If it is not, the file has not been modified since the last backup and can be skipped this time. On the other hand, if the modification date is more recent than the last backup date, the file has been modified and should be backed up. Incremental backups are used in conjunction with a regularly-occurring full backup (for example, a weekly full backup, with daily incrementals). The primary advantage gained by using incremental backups is that the incremental backups run more quickly than full backups. The primary disadvantage to incremental backups is that restoring any given file may mean going through one or more incremental backups until the file is found. When restoring a complete file system, it is necessary to restore the last full backup and every subsequent incremental backup. In an attempt to alleviate the need to go through every incremental backup, a slightly different approach was implemented. This is known as the differential backup .

Commands:
Chapter 2. Enable the RHEL for SAP Applications or RHEL for SAP Solutions subscriptions For running SAP NetWeaver application servers the "RHEL for SAP Applications" subscription can be used if the RHEL systems don't need to be locked to a specific RHEL 8 minor release. For running SAP HANA or SAP NetWeaver or S/4HANA application servers that should be tied to the same RHEL 8 minor release as SAP HANA, one of the following subscriptions is required to access Update Services for SAP Solutions (E4S) : for the x86_64 platform: Red Hat Enterprise Linux for SAP Solutions for the PowerPC Little Endian ( ppc64le ) platform: Red Hat Enterprise Linux for SAP Solutions for Power, LE 2.1. Detach existing subscriptions (already registered systems only) Perform the following steps if the SAP System was previously registered using another RHEL subscription. Find the serial number of the subscription that the system is currently subscribed to: # subscription-manager list --consumed | \ awk '/Subscription Name:/|| /Serial:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}' Remove the subscription from the system, using the following command. Replace the string <SERIAL> by the serial number shown in the output of the command. # subscription-manager remove --serial=<SERIAL> 2.2. Attach the RHEL for SAP Applications or RHEL for SAP Solutions subscription To attach the RHEL for SAP Applications or RHEL for SAP Solutions subscriptions, perform the following steps: Find the pool id of the subscription: # subscription-manager list --available --matches='RHEL for SAP*' | \ awk '/Subscription Name:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}' Attach the subscription to the system, using the following command. Replace the string <POOL_ID> with the actual pool ID (or one of the pool IDs) shown in the output of the command. # subscription-manager attach --pool=<POOL_ID>

Commands:
subscription-manager list --consumed | awk '/Subscription Name:/|| /Serial:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}'
subscription-manager remove --serial=<SERIAL>
subscription-manager list --available --matches='RHEL for SAP*' | awk '/Subscription Name:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}'
subscription-manager attach --pool=<POOL_ID>
E.2.10. /proc/interrupts This file records the number of interrupts per IRQ on the x86 architecture. A standard /proc/interrupts looks similar to the following: For a multi-processor machine, this file may look slightly different: The first column refers to the IRQ number. Each CPU in the system has its own column and its own number of interrupts per IRQ. The column reports the type of interrupt, and the last column contains the name of the device that is located at that IRQ. Each of the types of interrupts seen in this file, which are architecture-specific, mean something different. For x86 machines, the following values are common: XT-PIC - This is the old AT computer interrupts. IO-APIC-edge - The voltage signal on this interrupt transitions from low to high, creating an edge , where the interrupt occurs and is only signaled once. This kind of interrupt, as well as the IO-APIC-level interrupt, are only seen on systems with processors from the 586 family and higher. IO-APIC-level - Generates interrupts when its voltage signal is high until the signal is low again.

Commands:
CPU0 0: 80448940 XT-PIC timer 1: 174412 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 10: 410964 XT-PIC eth0 12: 60330 XT-PIC PS/2 Mouse 14: 1314121 XT-PIC ide0 15: 5195422 XT-PIC ide1 NMI: 0 ERR: 0
CPU0 CPU1 0: 1366814704 0 XT-PIC timer 1: 128 340 IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 1 IO-APIC-edge rtc 12: 5323 5793 IO-APIC-edge PS/2 Mouse 13: 1 0 XT-PIC fpu 16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro 10/100 Ethernet 20: 8450043 11120093 IO-APIC-level megaraid 30: 10432 10722 IO-APIC-level aic7xxx 31: 23 22 IO-APIC-level aic7xxx NMI: 0 ERR: 0
Chapter 1. Guide Overview The purpose of this guide is to walk through the steps that need to be completed prior to booting up the Red Hat Single Sign-On server for the first time. If you just want to test drive Red Hat Single Sign-On, it pretty much runs out of the box with its own embedded and local-only database. For actual deployments that are going to be run in production you'll need to decide how you want to manage server configuration at runtime (standalone or domain mode), configure a shared database for Red Hat Single Sign-On storage, set up encryption and HTTPS, and finally set up Red Hat Single Sign-On to run in a cluster. This guide walks through each and every aspect of any pre-boot decisions and setup you must do prior to deploying the server. One thing to particularly note is that Red Hat Single Sign-On is derived from the JBoss EAP Application Server. Many aspects of configuring Red Hat Single Sign-On revolve around JBoss EAP configuration elements. Often this guide will direct you to documentation outside of the manual if you want to dive into more detail. 1.1. Recommended Additional External Documentation Red Hat Single Sign-On is built on top of the JBoss EAP application server and its sub-projects like Infinispan (for caching) and Hibernate (for persistence). This guide only covers basics for infrastructure-level configuration. It is highly recommended that you peruse the documentation for JBoss EAP and its sub projects. Here is the link to the documentation: JBoss EAP Configuration Guide

Commands:
5.9.8.2. After Red Hat Enterprise Linux Has Been Installed Creating a RAID array after Red Hat Enterprise Linux has been installed is a bit more complex. As with the addition of any type of disk storage, the necessary hardware must first be installed and properly configured. Partitioning is a bit different for RAID than it is for single disk drives. Instead of selecting a partition type of "Linux" (type 83) or "Linux swap" (type 82), all partitions that are to be part of a RAID array must be set to "Linux raid auto" (type fd). , it is necessary to actually create the RAID array. This is done with the mdadm program (refer to man mdadm for more information). The RAID array /dev/md0 is now ready to be formatted and mounted. The process at this point is no different than for formatting and mounting a single disk drive.

Commands:
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/hd[bc]1 mdadm --detail --scan > /dev/mdadm.conf
11.15. Namespaces for Extension Metadata When defining the extension metadata in the case of Custom Translators, the properties on tables/views/procedures/columns can define namespace for the properties such that they will not collide with properties specific to JBoss Data Virtualization. The property should be prefixed with alias of the Namespace. Prefixes starting with teiid_ are reserved for use by JBoss Data Virtualization. See "option namespace" in Section A.7, "Productions" . Example 11.8. Example of Namespace Table 11.1. Built-in Namespace Prefixes Prefix URI Description teiid_rel http://www.teiid.org/ext/relational/2012 Relational extensions. Uses include function and native query metadata teiid_sf http://www.teiid.org/translator/salesforce/2012 Salesforce extensions.

Commands:
SET NAMESPACE 'http://custom.uri' AS foo CREATE VIEW MyView (...) OPTIONS ("foo:mycustom-prop" 'anyvalue')
Chapter 106. KafkaConnectStatus schema reference Used in: KafkaConnect Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. url string The URL of the REST API endpoint for managing and monitoring Kafka Connect connectors. connectorPlugins ConnectorPlugin array The list of connector plugins available in this Kafka Connect deployment. replicas integer The current number of pods being used to provide this resource. labelSelector string Label selector for pods providing this resource.

Commands:
5.2. Load Balancing Policy Load balancing policy is set for a cluster, which includes one or more hosts that may each have different hardware parameters and available memory. The Red Hat Virtualization Manager uses a load balancing policy to determine which host in a cluster to start a virtual machine on. Load balancing policy also allows the Manager determine when to move virtual machines from over-utilized hosts to under-utilized hosts. The load balancing process runs once every minute for each cluster in a data center. It determines which hosts are over-utilized, which are hosts under-utilized, and which are valid targets for virtual machine migration. The determination is made based on the load balancing policy set by an administrator for a given cluster. The options for load balancing policies are VM_Evenly_Distributed , Evenly_Distributed , Power_Saving , Cluster_Maintenance , and None .

Commands:
13.3. Build and Deploy the Hello World Quickstart Before building and deploying the quickstart, ensure that all the listed prerequisites are met and that the two application server instances are running (see Section 13.2, "Start Two Application Server Instances" for details). Procedure 13.3. Build and Deploy the Hello World Quickstart Navigate to the Required Directory In the command line terminal, navigate to the root directory of the quickstart on the command line interface. Build and Deploy to the First Application Server Instance Use the following command to build and deploy the quickstart to the first application server instance as follows: This command deploys target/ jboss-helloworld-jdg.war to the first running server instance. Build and Deploy to the Second Application Server Instance Use the following command to build and deploy the quickstart to the second application server instance with the specified ports as follows: This command deploys target/ jboss-helloworld-jdg.war to the second running server instance. Report a bug

Commands:
mvn clean package jboss-as:deploy
mvn clean package jboss-as:deploy -Djboss-as.port=10099
Chapter 14. Security OpenSSH chroot Shell Logins Generally, each Linux user is mapped to an SELinux user using SELinux policy, enabling Linux users to inherit the restrictions placed on SELinux users. There is a default mapping in which Linux users are mapped to the SELinux unconfined_u user. In Red Hat Enterprise Linux 7, the ChrootDirectory option for chrooting users can be used with unconfined users without any change, but for confined users, such as staff_u, user_u, or guest_u, the SELinux selinuxuser_use_ssh_chroot variable has to be set. Administrators are advised to use the guest_u user for all chrooted users when using the ChrootDirectory option to achieve higher security. OpenSSH - Multiple Required Authentications Red Hat Enterprise Linux 7 supports multiple required authentications in SSH protocol version 2 using the AuthenticationMethods option. This option lists one or more comma-separated lists of authentication method names. Successful completion of all the methods in any list is required for authentication to complete. This enables, for example, requiring a user to have to authenticate using the public key or GSSAPI before they are offered password authentication. GSS Proxy GSS Proxy is the system service that establishes GSS API Kerberos context on behalf of other applications. This brings security benefits; for example, in a situation when the access to the system keytab is shared between different processes, a successful attack against that process leads to Kerberos impersonation of all other processes. Changes in NSS The nss packages have been upgraded to upstream version 3.15.2. Message-Digest algorithm 2 (MD2), MD4, and MD5 signatures are no longer accepted for online certificate status protocol (OCSP) or certificate revocation lists (CRLs), consistent with their handling for general certificate signatures. Advanced Encryption Standard Galois Counter Mode (AES-GCM) Cipher Suite (RFC 5288 and RFC 5289) has been added for use when TLS 1.2 is negotiated. Specifically, the following cipher suites are now supported: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256; TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256; TLS_DHE_RSA_WITH_AES_128_GCM_SHA256; TLS_RSA_WITH_AES_128_GCM_SHA256. New Boolean Names Several SELinux boolean names have been changed to be more domain-specific. The old names can still be used, however, only the new names will appear in the lists of booleans. The old boolean names and their respective new names are available from the /etc/selinux/<policy_type>/booleans.subs_dist file. SCAP Workbench SCAP Workbench is a GUI front end that provides scanning functionality for SCAP content. SCAP Workbench is included as a Technology Preview in Red Hat Enterprise Linux 7. You can find detailed information on the website of the upstream project: https://fedorahosted.org/scap-workbench/ OSCAP Anaconda Add-On Red Hat Enterprise Linux 7 introduces the OSCAP Anaconda add-on as a Technology Preview. The add-on integrates OpenSCAP utilities with the installation process and enables installation of a system following restrictions given by SCAP content.

Commands:
3.9. Searching for Clusters The following table describes all search options for clusters. Table 3.5. Searching Clusters Property (of resource or resource-type) Type Description (Reference) Datacenter. datacenter-prop Depends on property type The property of the data center associated with the cluster. Datacenter String The data center to which the cluster belongs. name String The unique name that identifies the clusters on the network. description String The description of the cluster. initialized String True or False indicating the status of the cluster. sortby List Sorts the returned results by one of the resource properties. page Integer The page number of results to display. Example Clusters: initialized = true or name = Default This example returns a list of clusters which are initialized or named Default.

Commands:
7.117. lsscsi 7.117.1. RHBA-2015:0798 - lsscsi bug fix update Updated lsscsi packages that fix one bug are now available for Red Hat Enterprise Linux 6. The lsscsi utility uses information provided by the sysfs pseudo file system in Linux kernel 2.6 and later series to list small computer system interface (SCSI) devices or all SCSI hosts attached to the system. Options can be used to control the amount and form of information provided for each device. Bug Fix BZ# 1009883 The lsscsi package has been updated to properly detect and decode the SCSI "protection_type" and "integrity" flags. Previously, the lsscsi package tried to read the "protection_type" and "integrity" flags from a location in the sysfs file system where they were not expected to be found. With this update, lsscsi now uses the proper file locations to identify these flags. Users of lsscsi are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 9. LDAP Servers LDAP (Lightweight Directory Access Protocol) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500 standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as " X.500 Lite " . Like X.500, LDAP organizes information in a hierarchical manner using directories. These directories can store a variety of information such as names, addresses, or phone numbers, and can even be used in a manner similar to the Network Information Service ( NIS ), enabling anyone to access their account from any machine on the LDAP enabled network. LDAP is commonly used for centrally managed users and groups, user authentication, or system configuration. It can also serve as a virtual phone directory, allowing users to easily access contact information for other users. Additionally, it can refer a user to other LDAP servers throughout the world, and thus provide an ad-hoc global repository of information. However, it is most frequently used within individual organizations such as universities, government departments, and private companies. 9.1. Red Hat Directory Server Red Hat Directory Server is an LDAP-compliant server that centralizes user identity and application information. It provides an operating system-independent and network-based registry for storing application settings, user profiles, group data, policies, and access control information. Note You require a current Red Hat Directory Server subscription to install and update Directory Server. For further details about setting up and using Directory Server, see: Red Hat Directory Server Installation Guide Red Hat Directory Server Deployment Guide Red Hat Directory Server Administration Guide Red Hat Directory Server Configuration, Command, and File Reference Red Hat Directory Server Performance Tuning Guide

Commands: